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]
Message-ID: <20120220235619.GH5752@somewhere.redhat.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ