At Tue, 12 Jun 2012 14:03:10 +0200 (CEST), Oliver Fromme wrote: > > Momchil Ivanov <[email protected]> wrote: > > I was just curious why both processes are hopping around, > > because I would naively think that should not happen. > > I'll try to explain ... > > There are always many more processes and threads being executed > beside the two CPU-bound ones that you see at the top of the > top(1) display. For example, there are at least 15 threads > inside the kernel (see "ps -auxww") that are scheduled every > now and then. Or look at "vmstat -i" output to see the > interrupt statistics: Several hundred times per second, > the interrupt handlers have to be executed. > > So, what happens is that an interrupt occurs (from a hardware > clock, from a hard disk controller, from an input device, or > anything else). Then your process is _removed_ from the core > on which it is currently executing, and the interrupt handler > starts executing. The same can happen on the second core at > the same time, because different kernel threads can execute > simultaneously (if they don't share resources). Now, if the > interrupt handler on one of the two cores is done, your own > process has a chance to be scheduled again. In this moment, > it does not matter at all on which core it is going to be > executed. The only difference is cache contents, but the > first-level-caches are usually too small anyway. The ULE > scheduler takes a lot of information into account when making > the decision, including cache affinity (the 4BSD scheduler > doesn't know about that at all).
So the L2 cache is shared between both cores and hence it's size does not matter at all? _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
