Re: RFC: THE OFFLINE SCHEDULER

[Christoph Lameter]

On Wed, 26 Aug 2009, Peter Zijlstra wrote:

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

Right. We discussed this. Why are you repeating the same old arguments?

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

Its pretty simple. Just isolate the cpu, forbid the OS to run anything on
it. Allow a user space process to change its affinity to the isolated cpu.
Should the process be so stupid as to ask the OS for services then just
switch it back to a regular processor. Interaction is still possible via
shared memory communication as well as memory mapped devices.

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

What special case? This is a generic mechanism.

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

Shared memory, memory mapped devices?

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

Yes and there are mechanism that provide the serialization without OS
services.

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

Right. I also want to use it for network stuff. Infiniband which support
memory mapped registers and stuff. Its generic not special as you state.

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

Well yes you need to create synchronization methods that do not require OS
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.

Dont have one here. Whats a sod off?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/