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 17:30:25 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	raz ben yehuda <raziebe@...il.com>
Cc:	Maxim Levitsky <maximlevitsky@...il.com>,
	Christoph Lameter <cl@...ux-foundation.org>,
	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 17:54 +0300, raz ben yehuda wrote:
> This is exactly what offsched (sos) is. you got it. SOS was partly
> inspired by the notion of a GPU. 

It is not, GPUs and other paired chips form a hybrid system. Linux is
known to run on one or more of such chips and communicate through
whatever means these chips have.

But what you propose here is hard partitioning a homogeneous system,
totally different.

> Processors are to become more and more redundant and Linux as an
> evolutionary system must use it. why not offload raid5 write engine ?
> why not encrypt in a different processor ?

Why waste a whole cpu for something that could be done by part of one?

> Also , having so many processors in a single OS means a bug prone
> system , with endless contention points when two or more OS processors
> interacts. 

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.

> let's make things simpler.

You don't, you make things more complex by introducing duplicate
functionality.

What's more, you burden the user with having to configure such a system,
and make choices on having to give up parts of his system, nothing like
that should be needed on a homogeneous system.

Work spend on trimming fat of of the core kernel helps everybody, even
users not otherwise interested in things like giving up a whole cpu for
some odd purpose.

There is no reason something could be done more efficiently on a
dedicated CPU than not when you assume a homogeneous system (which is
all Linux supports in the single image sense).

If you think the kernel is too fat and does superfluous things for your
needs, help trim it.

--
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/