linux-kernel - Re: RFC: THE OFFLINE SCHEDULER

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 Aug 2009 18:03:18 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	raz ben yehuda <raziebe@...il.com>,
	Maxim Levitsky <maximlevitsky@...il.com>,
	Chris Friesen <cfriesen@...tel.com>,
	Mike Galbraith <efault@....de>, riel@...hat.com, mingo@...e.hu,
	andrew motron <akpm@...ux-foundation.org>,
	wiseman@...s.biu.ac.il, lkml <linux-kernel@...r.kernel.org>,
	linux-rt-users@...r.kernel.org
Subject: Re: RFC: THE OFFLINE SCHEDULER

On Wed, 2009-08-26 at 11:41 -0400, Christoph Lameter wrote:
> On Wed, 26 Aug 2009, Peter Zijlstra wrote:
> 
> > Why waste a whole cpu for something that could be done by part of one?
> 
> Because of latency and performance requirements

Latency is the only one, and yes people have been using hacks like this,
I've also earlier mentioned RTAI, RTLinux and L4-Linux which basically
do the same thing.

The problem is, that its not linux, you cannot run something on a these
off-cores and use the same functionality as linux, if you could it'd not
be offline.

The past year or so you've been whining about the tick latency, and I've
seen exactly _0_ patches from you slimming down the work done in there,
even though I pointed out some obvious things that could be done.

Carving out cpus just doesn't work in the long run (see below for more),
it adds configuration burdens on people and it would duplicate
functionality (below), or it provides it in a (near) useless manner.

If you were to work on lowering the linux latency in the full kernel
sense, you'd help out a lot of people, many use-cases would improve and
you'd be helpful to he greater good.

If you hack up special cases like this, then only your one use-case gets
better and the rest doesn't, or it might actually get worse, because it
got less attention.

> > You're bound to have interaction between the core os and these
> > partitions you want, non of it different from how threads in the kernel
> > would interact, other than that you're going to re-invent everything
> > already present in the kernel.
> 
> The kernel interactions can be done while running on another (not
> isolated) cpu.

There needs to be some communication between the isolated and non
isolated part, otherwise what's the point. Even when you'd let it handle
say a network device as pure firewall, you'd need to configure the
thing, requiring interaction.

Interaction of any sorts gets serialization requirements, and from there
on things tend to grow.

> > You don't, you make things more complex by introducing duplicate
> > functionality.
> 
> The functionality does not exist. This is about new features.

It is not, he is proposing to use these cores for:

 - network stuff, we already have that
 - raid5 stuff, we already have that
 - other stuff we already have

Then there is the issue of what happens when a single core isn't
sufficient for the given task, then you'd need to split up, again
creating more interaction.

> > If you think the kernel is too fat and does superfluous things for your
> > needs, help trim it.
> 
> Mind boogling nonsense. Please stop fantasizing and trolling.

Oh, to lay down the crack-pipe and sod off.
--
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/