lkml.org 
[lkml]   [2001]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: Over 4-way systems considered harmful :-)
    Date
    > -----Original Message-----
    > From: linux-kernel-owner@vger.kernel.org
    > [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Martin J. Bligh
    > Sent: Tuesday, December 04, 2001 9:41 AM
    > To: M. Edward Borasky; linux-kernel@vger.kernel.org
    > Subject: Re: Over 4-way systems considered harmful :-)
    >
    > Two things.
    >
    > 1) If a company (say, IBM) pays people to work on 8 / 16 way scalability
    > because that's what they want out of Linux, then stopping development
    > on that isn't going to get effort redirected to fixing your
    > soundcard (yes,
    > I realise you were being flippant, but the point's the same), the
    > headcount
    > is just going to disappear. AKA your choice isn't "patches for 8 way
    > scalablilty, or patches for subsystem X that you're more interested in",
    > your choice is "patches for 8-way scalabity, or no patches". Provided that
    > those patches don't break anything else, you still win overall by
    > getting them.

    I don't see how this is a win for me. And it is a win for IBM only if it
    gives them some advantage in serving their customers. I can certainly
    *conceive* of workloads bursty enough to justify an 8-processor server, but
    do they exist in the real world? And if they do, is a single 8-processor
    server better than a pair of 4-processor servers when you take graceful
    handling of faults into account? IBM has been building high-availability
    systems for *decades*, preferring to field *slightly* slower but
    *significantly* more reliable gear, which, legend has it, no one has ever
    been fired for purchasing. :-)

    > 2) Working on scalability for 8 / 16 way machines will show up races,
    > performance problems et al that exist on 2 / 4 way machines but don't
    > show up as often, or as obviously. I have a 16 way box that shows up
    > races in the Linux kernel that might take you years to find on a 2 way.

    Perhaps effort should be placed into software development processes and
    tools that deny race conditions the right to be born, rather than depending
    on testing on a 16-processor system to find them expeditiously :-). And
    there is a whole discipline of software performance engineering to build
    performance in from the start. Advances like that would be a *huge* win for
    the Linux community, given our (relative) freedom from corporate-world
    limitations like deadlines, sales quotas, programmer salaries, and
    full-color brochures.

    > What I'm trying to say is that you still win. Not as much as maybe you'd
    > like, but, hey, it's work you're getting for free, so don't complain too
    > much about it. The maintainers are very good at beating the message
    > into us that we can't make small systems any worse performing whilst
    > making the big systems better.

    No, but we can release partly-baked VM schemes that have a shelf life on the
    order of days :-). Seriously, though, I don't like stepping on someone
    else's dream, especially since *my* dream -- a GFLOP dedicated to computer
    music -- has been fulfilled for about $1500 US. When I bought that machine,
    I thought I was going to need two processors -- one to run the OS and
    service the keyboard, mouse and monitor and a second dedicated to generating
    audio samples in real time. I had no idea how powerful these chips were
    until I started shopping around. And when I loaded the Atlas linear algebra
    library up on my Athlon and saw the speeds it was getting, I was in shock
    for almost a week!

    However, as I said in another post: "Moore's Law: good. Amdahl's Law: bad."
    I guess the new generation has to discover Amdahl's Law for itself, and
    *this* distinguished but elderly scientist is eager to be proven wrong :-).
    --
    Take Your Trading to the Next Level!
    M. Edward Borasky, Meta-Trading Coach

    znmeb@borasky-research.net
    http://www.meta-trading-coach.com
    http://groups.yahoo.com/group/meta-trading-coach

    -
    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: 2005-03-22 13:13    [W:3.413 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site