lkml.org 
[lkml]   [2009]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: RFC: THE OFFLINE SCHEDULER
    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


    \
     
     \ /
      Last update: 2009-08-27 23:15    [W:0.029 / U:3.868 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site