linux-kernel - Re: NoHZ and CPU isolation patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 21 Feb 2012 00:56:22 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Max Krasnyansky <maxk@...lcomm.com>
Cc:	Gilad Ben-Yossef <gilad@...yossef.com>,
	linux-kernel@...r.kernel.org
Subject: Re: NoHZ and CPU isolation patches

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@...lcomm.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/