Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Feb 2014 03:14:04 +0100
From:      Matthias Andree <matthias.andree@gmx.de>
To:        freebsd-hackers@freebsd.org
Subject:   Re: can the scheduler decide to schedule an interrupted but runnable thread on another CPU core? What are the implications for code?
Message-ID:  <52FD7BEC.9050807@gmx.de>
In-Reply-To: <CAJ-Vmo=7Nz1jqXy%2BrTQ7u9_ZP7jeFOKUJxU1O51tYJjvTUmWTg@mail.gmail.com>
References:  <CAJ-Vmo=7Nz1jqXy%2BrTQ7u9_ZP7jeFOKUJxU1O51tYJjvTUmWTg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52FD7BEC.9050807>