lkml.org 
[lkml]   [2007]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: sched_yield: delete sysctl_sched_compat_yield
    Date
    On Monday 03 December 2007 20:57, Ingo Molnar wrote:
    > * Nick Piggin <nickpiggin@yahoo.com.au> wrote:
    > > > as far as desktop apps such as firefox goes, the exact opposite is
    > > > true. We had two choices basically: either a "more agressive" yield
    > > > than before or a "less agressive" yield. Desktop apps were reported
    > > > to hurt from a "more agressive" yield (firefox for example gets some
    > > > pretty bad delays), so we defaulted to the less agressive method.
    > > > (and we defaulted to that in v2.6.23 already)
    > >
    > > Yeah, I doubt the 2.6.23 scheduler will be usable for distros
    > > though...
    >
    > ... which is a pretty gross exaggeration belied by distros already
    > running v2.6.23. Sure, "enterprise" distros might not run .23 (or .22 or

    Yeah, that's what I mean of course. And it's because of the performance
    and immediate upstream divergence issues with 2.6.23. Specifically I'm
    talking about the scheduler: they may run a base 2.6.23, but it would
    likely have most or all subsequent scheduler patches.


    > > I was just talking about the default because I didn't know the reason
    > > for the way it was set -- now that I do, we should talk about trying
    > > to improve the actual code so we don't need 2 defaults.
    >
    > I've got the patch below queued up: it uses the more agressive yield
    > implementation for SCHED_BATCH tasks. SCHED_BATCH is a natural
    > differentiator, it's a "I dont care about latency, it's all about
    > throughput for me" signal from the application.

    First and foremost, do you realize that I'm talking about existing
    userspace working well on future kernels right? (ie. backwards
    compatibility).


    > But first and foremost, do you realize that there will be no easy
    > solutions to this topic, that it's not just about 'flipping a default'?

    Of course ;) I already answered that in the email that you're replying
    to:

    > > I was just talking about the default because I didn't know the reason
    > > for the way it was set -- now that I do, we should talk about trying
    > > to improve the actual code so we don't need 2 defaults.

    Anyway, I'd hope it can actually be improved and even the sysctl
    removed completely.


    \
     
     \ /
      Last update: 2007-12-03 11:19    [W:0.021 / U:0.880 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site