can the scheduler decide to schedule an interrupted but runnable thread on another CPU core? What are the implications for code?

[Matthias Andree]

Am 14.02.2014 00:57, schrieb Adrian Chadd:
> Hi,
> 
> Whilst digging into collisions in the flowtable code I discovered that
> a bunch of them are due to some of the flowtable_lookup() code running
> on a different CPU - the contention on the l2/l3 lookup lock(s) was
> enough to block things so they'd get an obvious chance to be migrated.
> 
> So this led me to wonder whether in a fully preemptive kernel, a
> running kernel thread would stay on the current CPU until it hit a
> very specific subset of things (exited to userland, hit a lock, etc.)
> 
> Apparently (according to kan and rwatson) this is how we define fully
> preemptive - it's not just interruptable at almost any point, but the
> running task may be interrupted and rescheduled on a different CPU
> outside of specific critical sections.

There's one more question to ask, and that is if you have a thread that
warmed up its caches and you migrate it to a different core - what
happens with the execution time?  It might become longer because you
don't usually share or migrate the L1/L2 cache contents, so I'd naively
expect lower cache hit ratios.  Certainly there is not a simple answer
to that, but should someone start thinking about scheduler
implementations, the "setup overhead" for the switch to a different core
might be relevant.  (Whether it's really more than the extra effort a
scheduler would require to spend to make a better decision is then yet
one more question.)