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]

Message-ID: <alpine.LFD.2.00.0908281057070.2888@localhost.localdomain>
Date:	Fri, 28 Aug 2009 12:05:22 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	raz ben yehuda <raziebe@...il.com>
cc:	Chris Friesen <cfriesen@...tel.com>,
	Andrew Morton <akpm@...ux-foundation.org>, mingo@...e.hu,
	peterz@...radead.org, maximlevitsky@...il.com, efault@....de,
	riel@...hat.com, wiseman@...s.biu.ac.il,
	linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org
Subject: Re: RFC: THE OFFLINE SCHEDULER

On Fri, 28 Aug 2009, raz ben yehuda wrote:
> On Fri, 2009-08-28 at 00:05 +0200, Thomas Gleixner wrote:
> > This is totally irrelevant and we all know how communication channels
> > between Linux and whatever hackery (RT-Linux, RTAI, ... OFFLINE)
> > works.
>
> Why are you referring to the above projects as hacks ? What is a hack ?

Everything which works around the real problem instead of solving it.

> > > 2. know **exactly*** how much each single packet transmission costs. for
> > > example, in this case in processor 3 a single packet average
> > > transmission is 1974tscs, which is ~700ns.
> > > 
> > > 3. know how many packets fails to transmit right **on time** ( the Lates
> > > counter) . and on time in this case means within the 122us jitter. 
> > 
> > Are those statistics a crucial property of your OFFLINE thing ?

> yes. latency is a crucial property. 

You are not answering my quesiton.

Also reducing latencies is something we want to do in the kernel
proper in the first place. We all know that you can reduce the
latencies by taking control away from the kernel and running a side
show. But that's nothing new. It has been done for decades already and
none of these projects has ever improved the kernel itself.

> > > 4. There are 8 cores in this machine. The rest 4 OS cores are ~95% idle.
> > > The only resource these cores share is the bus. 
> > 
> > That does not change the problem that you cannot run ordinary user
> > space tasks on your offlined CPUs and you are simply hacking round the
> > real problem which I outlined in my previous mail.
>
> OFFSCHED is not just about RT. it is about assigning assignments to
> another resource outside the operating system. very much like GPUs,
> network processors, and so on, but just with software that is
> accessible to the OS.

I was not talking about RT. I was talking about the problem that you
cannot run an ordinary user space task on your offlined CPU. That's
the main point where the design sucks. Having specialized programming
environments which impose tight restrictions on the application
programmer for no good reason are horrible.

Also how are GPUs, network processors related to my statements ?
Running specialized software on dedicated hardware which is an addon
to the base system controlled by the kernel is not new. There are
enough real world applications running Linux on the main CPU and some
extra code on an add on DSP or whatever. Cell/SPU or the TI ARM/DSP
combos are just the most obvious examples which come to my mind. Where
is the point of OFFSCHED here ?

In your earlier mails you talked about isolating cores of the base
system by taking the control away from the kernel and what a wonderful
solution this is because it allows you full control over that core.

We can dedicate a core to special computations today and we can assign
resources of any kind to it under the full control of the OS. The only
disturbing factor is the scheduler tick.

So you work around the scheduler tick problem by taking the core away
from the OS. That does not solve the problem, it simply introduces a
complete set of new problems:

 - accounting of CPU utilization excludes the offlined core

 - resource assignment is restricted to startup of the application

 - standard admin tools (top, ps ....) are not working

 - unnecessary restrictions for the application programmer:
    - no syscalls
    - no standard IPC
    - ....

 - debugging of the code which runs on the offlined core needs
   separate tools

 - performance analysis e.g. with profiling/performance counters
   cannot use the existing mechanisms

 - ....

Thanks,

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