On Wed, 2009-08-26 at 07:31 +0200, Peter Zijlstra wrote:

On Tue, 2009-08-25 at 13:22 -0600, Chris Friesen wrote:

quoted

On 08/25/2009 01:08 PM, Peter Zijlstra wrote:

quoted

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.

Is it the whole concept of isolating one or more cpus from all normal
kernel tasks that you don't like, or just this particular implementation?

I ask because I know of at least one project that would have used this
capability had it been available.  As it stands they have to live with
the usual kernel threads running on the cpu that they're trying to
dedicate to their app.

Its the simple fact of going around the kernel instead of using the
kernel.

Going around the kernel doesn't benefit anybody, least of all Linux.

So its the concept of running stuff on a CPU outside of Linux that I
don't like. I mean, if you want that, go ahead and run RTLinux, RTAI,
L4-Linux etc.. lots of special non-Linux hypervisor/exo-kernel like
things around for you to run things outside Linux with.

Hello Peter, Hello All.
First , It a pleasure seeing that you take interest in OFFSCHED. 
So thank you. 

To my opinion this a matter of defining what a system is. Queuing theory
teaches us that a system is defined to be everything within the boundary
of the computer, this includes, peripherals, processors, RAM , operating
system, the distribution and so on.  
The kernel is merely a part of the SYSTEM, it is not THE SYSTEM; and it
is not a blasphemy to bypass it.The kernel is not the goal and it is not
sacred. 
OFFSCHED is bad name to my project. My project is called SOS = Service
Oriented System.
SOS, has nothing to do with Real time. SOS is about arranging the
processors to serve the SYSTEM the best way we can; if the kernel
disturbs the service, put it a side I say. 

How will the kernel is going to handle 32 processors machines ?  These
numbers are no longer a science-fiction.

What i am suggesting is merely a different approach of how to handle
multiple core systems. instead of thinking in processes, threads and so
on i am thinking in services. Why not take  a processor and define this
processor to do just firewalling ? encryption ? routing ? transmission ?
video processing... and so on... 

Raz