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-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
