ULE Scheduler

[Momchil Ivanov]

At Tue, 12 Jun 2012 14:03:10 +0200 (CEST),
Oliver Fromme wrote:
> 
> Momchil Ivanov <momchil at xaxo.eu> 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?