lkml.org 
[lkml]   [2006]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] sched: Fix adverse effects of NFS client on interactive response
    Date
    On Fri, 6 Jan 2006 11:02 am, Peter Williams wrote:
    > Con Kolivas wrote:
    > > On Fri, 6 Jan 2006 10:13 am, Peter Williams wrote:
    > >>If the plugsched patches were included in -mm we could get wider testing
    > >>of alternative scheduling mechanisms. But I think it will take a lot of
    > >>testing of the new schedulers to allay fears that they may introduce new
    > >>problems of their own.
    > >
    > > When I first generated plugsched and posted it to lkml for inclusion in
    > > -mm it was blocked as having no chance of being included by both Ingo and
    > > Linus and I doubt they've changed their position since then. As you're
    > > well aware this is why I gave up working on it and let you maintain it
    > > since then. Obviously I thought it was a useful feature or I wouldn't
    > > have worked on it.
    >
    > I've put a lot of effort into reducing code duplication and reducing the
    > size of the interface and making it completely orthogonal to load
    > balancing so I'm hopeful (perhaps mistakenly) that this makes it more
    > acceptable (at least in -mm).

    The objection was to dilution of developer effort towards one cpu scheduler to
    rule them all. Linus' objection was against specialisation - he preferred one
    cpu scheduler that could do everything rather than unique cpu schedulers for
    NUMA, SMP, UP, embedded... Each approach has its own arguments and there
    isn't much point bringing them up again. We shall use Linux as the
    "steamroller to crack a nut" no matter what that nut is.

    > My testing shows that there's no observable difference in performance
    > between a stock kernel and plugsched with ingosched selected at the
    > total system level (although micro benchmarking may show slight
    > increases in individual operations).

    I could find no difference either, but IA64 which does not cope with
    indirection well would probably suffer a demonstrable performance hit I have
    been told. I do not have access to such hardware.

    > Anyway, I'll just keep plugging away,

    Nice pun.

    Cheers,
    Con
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-01-06 01:10    [W:4.282 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site