Re: NoHZ and CPU isolation patches

[Frederic Weisbecker <fweisbec@gmail.com>]

On Tue, Feb 14, 2012 at 10:14:25AM -0800, Max Krasnyansky wrote:
> On 02/14/2012 01:44 AM, Gilad Ben-Yossef wrote:
> >Hi Max,
> >
> >Any specific reason not to CC the LKML list? I know it is sometime
> >noisy and I understand
> >you are not subscribed, but it is the Right Thing (tm) to do...
> 
> No reason really. I was just going to keep it short and basically just ask
> for CCs on future discussions :).
> Looks like this might turn into a useful discussion. Added to the CC.
> 
> >On Tue, Feb 14, 2012 at 5:55 AM, Max Krasnyansky<maxk@qualcomm.com>  wrote:
> >>Gilad, Frederic,
> >>
> >>At the time a lot of people
> >>were totally opposed to that
> >>from the recent threads it looks like things have changed quite a bit.
> >
> >I think people like the idea of CPU isolation, there is just the
> >question of what CPU
> >isolation means :-)
> >
> >At least my personal approach is that if a task is running on an
> >isolated CPU has caused
> >the kernel to need to do work on that CPU, that is fair game.
> Yep. My definition is the same. ie If a task wants to avoid interference from the
> kernel it better not use any syscalls() or at least not the syscalls that trigger
> IO, mem allocations, etc.

Right but we want a solution that works for everyone: those who need to issue syscalls
from time to time (IO or whatever), those who don't issue syscalls at all, etc...

So unplugging the CPU might work for pure isolation (no syscalls, no irq, no exception)
but there may be lighter kind of isolation, with rare syscalls, exceptions or irqs, etc...

If the task is disturbed for useless work, then lets fix that. This may be useful for
isolation and even much more globally.

Note that unplugging the CPU also prevents the task from any return to the kernel. This
include the do_exit() path. And I believe we don't want to deal with a CPU that is
not in the online mask when we enter such a complicated path.