Re: RFC: THE OFFLINE SCHEDULER

[Thomas Gleixner]

On Thu, 27 Aug 2009, Christoph Lameter wrote:
> On Thu, 27 Aug 2009, Chris Friesen wrote:
> 
> > I just went and read the docs.  One of the things I noticed is that it
> > says that the offlined cpu cannot run userspace tasks.  For our
> > situation that's a showstopper, unfortunately.
> 
> It needs to be implemented the right way. Essentially this is a variation
> on the isolcpu kernel boot option. We probably need some syscall to move
> a user space process to a bare metal cpu since the cpu cannot be
> considered online in the regular sense.

It can. It needs to be flagged as reserved for special tasks and you
need a separate mechanism to move and pin a task to such a CPU.

> An isolated cpu can then only execute one process at a time. A process
> would do all initialization and lock itsresources in memory before going
> to the isolated processor. Any attempt to use OS facilities need to cause
> the process to be moved back to a cpu with OS services.

You are creating a "one special case" operation mode which is not
justified in my opinion. Let's look at the problem you want to solve:

  Run exactly one thread on a dedicated CPU w/o any disturbance by the
  scheduler tick.

You can move away anything else than the scheduler tick from a CPU
today already w/o a single line of code change.

But you want to impose restrictions like resource locking and moving
back to another CPU in case of a syscall. What's the purpose of this ?
It does not buy anything except additional complexity.

That's just the wrong approach. All you need is a way to tell the
kernel that CPUx can switch off the scheduler tick when only one
thread is running and that very thread is running in user space. Once
another thread arrives on that CPU or the single thread enters the
kernel for a blocking syscall the scheduler tick has to be
restarted.

It's not rocket science to fix the well known issues of stopping and
eventually restarting the scheduler tick, the CPU time accounting and
some other small details. Such a modification would be of general use
contrary to your proposed solution which is just a hack to solve your
particular special case of operation.

Thanks,

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