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:	Tue, 25 Aug 2009 23:09:43 +0200
From:	Éric Piel <E.A.B.Piel@...elft.nl>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Christoph Lameter <cl@...ux-foundation.org>,
	Mike Galbraith <efault@....de>,
	raz ben yehuda <raziebe@...il.com>, 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

Op 25-08-09 21:08, Peter Zijlstra schreef:
> On Tue, 2009-08-25 at 14:03 -0400, Christoph Lameter wrote:
>> On Tue, 25 Aug 2009, Mike Galbraith wrote:
>>
>>> I asked the questions I did out of pure curiosity, and that curiosity
>>> has been satisfied.  It's not that I find it useless or whatnot (or that
>>> my opinion matters to anyone but me;).  I personally find the concept of
>>> injecting an RTOS into a general purpose OS with no isolation to be
>>> alien.  Intriguing, but very very alien.
>> Well lets work on the isolation piece then. We could run a regular process
>> on the RT cpu and switch back when OS services are needed?
> 
> Christoph, stop being silly, this offline scheduler thing won't happen,
> full stop.
> 
> Its not a maintainable solution, it doesn't integrate with existing
> kernel infrastructure, and its plain ugly.
> 
> If you want something work within Linux, don't build kernels in kernels
> or other such ugly hacks.
Hello,

For the one interested in such approach, you can have a look at an now
unmaintained project that we developed, ARTiS:
http://www2.lifl.fr/west/artis/

It allows several RT tasks to share a "RT" cpu, and if a task tries to
"cheat" by calling a kernel function which disables the preemption or
the interrupts, it is temporally migrated to another CPU. This is a
working approach, with some good low latency results which can be seen
in the papers on the website.

See you,
Eric
--
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/