|
None of it.
I/O has a tendency to occur in bursts. Processes that compute things tend to fill up buffers, when the buffers fill sufficiently, the I/O starts - it also means that the processes get delayed requesting additional buffers... Multiple threads allow for the compute processes to alternate - while some are filling buffer, others are having buffers emptied.
The general rule of thumb is to have two "ready to run" processes going for each core - that way the CPU is fairly busy... and the DMA can also be busy transferring data. Now the system still has some overhead to manage the processes, scheduling/sorting/consolidating buffers for I/O, so you do need something around 5% for the overhead. If you want to monitor the system then that gets counted as additional overhead. That means it would be nice to have an additional core not 100% loaded so that the monitoring isn't too sluggish.
In a desktop, you can roughly count the X server + window manager as a load for a single core. (when the window manager/applications are busy the X server is waiting for things to do). It won't be as responsive as an idle system... but it is usable. That leaves the rest of the cores available for compute processes. If you have 4 cores, that would imply that you should be able to have 6 compute bound processes and still have a relatively usable desktop.
Now there are a number of system configuration details that affect this - for instance, if you are using a desktop system based on cgroups (such as Fedora), you have less control - all processes started from within the desktop will contend for the CPU time - causing thrashing within that one cgroup. For these systems it would be much better to have the cpu bound processes under their own cgroup (one cgroup for each process) - that way they will each get a full share of the total CPU. Each cgroup scheduling then counts as a unit (6 for the compute processes + the desktop) leaving one for overhead.
This is part of the difference between servers and desktops. The configuration of a server is geared to making throughput a priority (which is what cgroups were designed for), rather than a desktop where the configuration is focused on making the desktop appear fast.
|
