Re: Reconciling Garbage Collection with Deterministic Finalization

Except for hard real-time applications, page faults are not much
of a problem, since they are guaranteed to only block for a short
time (even if there is a disk error, since then the process will be
terminated). There is obviously some latency associated with
servicing a page fault, but this is unavoidable regardless of the
concurrency design.

I don't see how you can argue that the latency of a page fault is
unavoidable. A page fault only stalls the faulting thread. A design
that permanently associates resources to threads, for example, will be
more crippled by a page fault than a design that allows whatever thread
happens to be running to grab a resource and handle it.

Consider, as an extreme example, two designs for the same server. They
both handle 10,000 clients with 100 threads. In one design, each client
is permanently assigned to a thread, 10 to each. In another design, the
clients that need work are put on a queue and a thread grabs a client
whenever it's free.

In the first design, if one client does something really unusual, that
causes code to fault in that isn't resident in memory, nine other
arbitrary connections will be stalled until the code faults in as well
as the client that triggered the fault. In the second design, the fault
will only affect the client that caused it (which did something rare
and unusual anyway), and other clients can be services by other
threads.

Consider also code that handles unusual error conditions. This type of
code is more likely to encounter page faults because the code is less
frequently used and less likely to be in memory. You can enter this
code while holding critical locks (thus stalling other threads while
the page fault is services) or you can carefully avoid doing so
(perhaps even dropping the lock and then re-acquiring it in the rarely
used code if appropriate).

So the argument that the latency of page faults is unavoidable
regardless of the design is misleading. Good design can minimize the
harm that page faults do and bad design can magnify it.

DS

.

Relevant Pages

  • Re: Ping Kevin Aylward - re your "scientific paper"
    ... If I design 100 circuits and one fails, ... of the decoding lies on the reader. ... intellectual food chain, but when I read your stuff it's as if I were ... it's my fault it's taking so long to get to the end of the ride. ...
    (sci.electronics.design)
  • Re: [performance] Is it safe to alter the meaning of STDOUT_FILENO in parent process rather than usi
    ... Poor software design includes poor software design in third-party libraries. ... This is otherwise called fault tolerance. ... fault isolation from each other. ... close all open file handles after fork but before exec. ...
    (comp.unix.programmer)
  • Re: Easy PC software tool - Bad experience
    ... In November 09 I had another design due for manufacture so I checked with Support that I had the required software fix and submitted the design for manufacture. ... The result to me was £1500 worth of PCBs being scrapped and an unhappy customer due to a missed delivery deadline. ... From the customer POV i.e. the important POV, the same fault re-occurred. ...
    (comp.arch.fpga)
  • Re: No more Freightliner sheds?
    ... the Blue Tiger locos. ... That's a design I liked, ... do fault finding on the road. ... This approach is not possible on hood-type locomotives such as classes ...
    (uk.railway)
  • Re: How many of your jobs are like this?
    ... power electronics for a third client at 9:00. ... for a product's design, documenting discussions/meetings, etc. ... cooler has run for 5h or so at half power, ...
    (comp.arch.embedded)