Re: Chat server : Threading in select call

David Schwartz <davids@xxxxxxxxxxxxx> wrote:
On Feb 12, 3:22 pm, William Ahern <will...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:

None of those solve the problem that an unexpected page fault can lead
to a latency spiral.

The same problem occurs with multi-threaded code, unless you have just as
many CPUs as threads.

No, that's not true. The page fault will cause another thread to run
on the same CPU. In fact, you will have the problem (at least in
principle) unless you have *more* threads than CPUs.

So when does the kernel get around to handling the fault? Say, for instance,
if the process hits the end of its stack, triggering a page fault, which the
kernel then has to attend to. That's _additional_ CPU instructions above and
beyond those which were executing when the process was in a presumptively
steady state. (You previously you mentioned faulting in error handling code,
IIRC.)

I'm failing to see how one sort of process could so easily fall behind in
this case, while in another sort of process (or set of processes) the
introduction of additional CPU instructions or I/O operations magically fits
within the existing resource caps (assuming you're operating near peak
throughput).

I can only presume you're alluding to the way modern kernels map in shared
libraries, and otherwise manage a shared disk buffer cache and virtual
memory. But if we're talking about long lived daemon processes servicing
tremendous amounts of network traffic, and operating at peak instructions
and I/O throughput, in many cases its not particularly hard to arrange it
(if necessary at all) so that parts of the process aren't evicted.

And unless you're on a real-time kernel, and have at your disposal all
manner of other neat guarantees, if your peering architecture is so
susceptiple to latency that quality perceptibly suffers there are other
issues.

Likewise, I can't imagine, for instance, a user would or should perceive
anything odd about receiving an IM message out of order by a few
milliseconds. (What does that even mean?)

.

Relevant Pages