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>