>>The main reason I write multithreaded apps for single CPU systems is to
>>protect against ambush. Consider, for example, a web server. Someone sends
>>it
>>an obscure request that triggers some code that's never run before and has
>>to
>>fault in. If my application were single-threaded, no work could be done
>>until
>>that page faulted in from disk.
>This is interesting--I hadn't considered this as most of my work for the
>past while has been on embedded systems with everything pinned in ram.
In the usual case, the code faults in.
>Have you benchmarked this? I was under the impression that the very
>fastest webservers were still single-threaded using non-blocking io.
It's all about how you define "fastest". If speed means being able to do the
same thing over and over really quickly, yes. But I also want uniform
(non-bursty) performance in the face of an unpredictable set of jobs.
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/