[lkml]   [2000]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Interesting analysis of linux kernel threading by IBM
    Friday, January 21, 2000 1:53 AM
    Larry McVoy <> wrote :

    Hi Larry,

    > : I really don't understand Your position.
    > : If we can have the same performance under "home" situations and be
    prepared to
    > : high load under either real world servers or benchmarks, why we don't do
    it ?
    > Because it is this line of reasoning that makes operating systems die.
    > You are micro optimizing for a particular case. That's just plain BAD
    > in an operating system. Special cases are BAD BAD BAD.
    > And I've heard a million times "it's only 1%" or "I benchmarked it and it
    > was the same". Of course it was only 1%, you only made one change. But
    > there are 100s of engineers all saying "it's only 1%".

    have You seen the current schedule() implementation ?
    It's filled of goto to keep a linear CPU fast-path with blocks with lower
    probability of execution
    kept in tail of the function block.
    To gain how in percent ?
    My patch, IMVHO is more clear then goto jump-back solution, under normal
    cases gives the same
    results, while under I load gives much better performance.

    > : Anyway I think benchmarks have their importance coz they drive servers
    > : decisions as long as stability issues.
    > Look, I'm world wide famous for my benchmarking skill. I think benchmarks
    > are important too but only if they represent a distilled version of
    > an application, not a contrived situation. I can contrive a million
    > different situations all of which are meaningless.

    Remeber that not always strategic decisions are taken by cultured ( in a
    computer science sense ) persons,
    otherwise Apple would defeat MSDOS and OS2 would defeat Windows 3.0.
    Anyway I prefer stability too, but if You can have both, why not ?

    > : High threaded applications gives a better results given that are well
    > : with a fine resource locking system.
    > Really? So what's the biggest application of that sort that you've
    > designed or substantially implemented? Anything as big as the kernel?
    > Me personally, I've worked on IRIX (scales to about 256 processors well,
    > and to 2048 poorly) and Solaris (scales to mebbe 64 on a good day,
    > usually more like 16-32). I've done in depth, multi year performance
    > work on both of those platforms. I was sitting next door to Steve
    > Kleiman when he was designing the SunOS multithreading architecture,
    > which heavily influenced the POSIX spec. We used to discuss this daily.

    Sorry I wouldn't have bothered a guru ;)
    I've sure a lower experience then Your but I continue to prefer a high
    application with fine grained locks.
    It'll be prepared for well scaling SMP systems, that IMVHO will be the
    future of computing,
    rather than uniprocessor ones with 1e99 gates ;)

    Anyway I'd like if You get a look at the patch.
    I think that a logarithmic scheduler, bechmarks apart, helps Linux SMP to
    scale better.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:56    [W:0.037 / U:31.520 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site