[lkml]   [2009]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 03/19] scheduler: implement workqueue scheduler class

    * Avi Kivity <> wrote:

    > On 10/01/2009 08:48 PM, Ingo Molnar wrote:
    >> We could do what Avi suggested: not use scheduler classes at all for
    >> this (that brings in other limitations like lack of p->policy freedom),
    >> but use the existing preempt-notifications callbacks.
    >> They are per task - we would simply make preempt notifiers
    >> unconditional, i.e. remove CONFIG_PREEMPT_NOTIFIERS and make it all
    >> unconditional scheduler logic.
    > Sure, but it would mean that we need a new notifier. sched_out,
    > sched_in, and wakeup (and, return to userspace, with the new
    > notifier).

    perf events have sched out, sched in and wakeup events. Return to
    user-space would be interesting to add as well. (and overhead of that
    can be hidden via TIF - like you did via the return-to-userspace

    Sounds more generally useful (and less scary) than (clever but somewhat
    limiting) sched_class hackery.

    I.e. i'd prefer if we had just one callback facility in those codepaths,
    minimizing the hotpath overhead and providing a coherent API.

    > btw, I've been thinking we should extend concurrency managed
    > workqueues to userspace. Right now userspace can spawn a massive
    > amount of threads, hoping to hide any waiting by making more work
    > available to the scheduler. That has the drawback of increasing
    > latency due to involuntary preemption. Or userspace can use one
    > thread per cpu, hope it's the only application on the machine, and go
    > all-aio.
    > But what if we added a way for userspace to tell the kernel to fork
    > off threads when processing power and work to do are both available?
    > The scheduler knows when there is processing power, and an epoll fd
    > can tell it when there is work to do. So the scheduler will create
    > threads to saturate the processors, if one of them waits for I/O the
    > scheduler forks off another one until all queues are busy again.

    Sounds like syslets done right?


     \ /
      Last update: 2009-10-01 21:19    [W:0.024 / U:60.836 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site