Disk I/O as a bottleneck?

Disk I/O as a bottleneck?

Gilboa Davara gilboad at gmail.com
Sun May 8 19:44:06 IDT 2011


On Sun, 2011-05-08 at 15:28 +0000, is123 at zahav.net.il wroteך
> As I said my development experience is on a different platform with a
> fundamentally different design. In that system, process forking is very
> expensive and threading is very cheap- the opposite of the *NIX model. And
> there are three or so decades of symmetric SMP exploitation so that stuff
> is done and works and is not part of ongoing development and doesn't
> break or cause problems and most of the software is designed to protect
> against application level misuse and resource contention and deadlocks by
> killing offending work to keep the system running well. Those kinds of
> protections are not available in Linux or BSD AFAIK. For example you cannot
> spin the processor on System Z from an application for very long without
> being killed by the supervisor, but you can easily write userland code to
> hog the machine in *NIX.
> 
> As *NIX was and is being changed to exploit SMP (and look at all the
> code that has been added let's say in the last 5 years to do this) it's
> very apparent to exploit the hardware threading is more useful than process
> forking. But that way of thinking is newish in *NIX and not all the tools
> and facilities (resource serialization etc) that are available in other
> systems (System Z for example) are available to *NIX so there are growing
> pains. A lot of progress has been made, no doubt. But there is still a lot
> of room for improvement.

I can't say that in my experience pthread_x under 2.6 Linux is heavier
or requires more resources than say, pthread or libthread under Solaris
(though my experience is somewhat dated).

Never the less, as I'm not sure we even agree on what the term "SMP
design" means, lets agree not to agree...

- Gilb




More information about the Linux-il mailing list