lkml.org 
[lkml]   [2000]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Help in DSM design
    Date
    From
    : > On Sat, 4 Mar 2000, Richard Gooch wrote:
    : > > Ach! Not another DSM project :-( Don't do it. There's already a DSM
    : >
    : > [dsm horror story]
    :
    : I swore I would avoid this argument but ...
    :
    : look, there's DSMs and there's DSMs. And there's different types of
    : applications. I've done a fair number of parallel apps and there are cases
    : where you can use DSM, and cases where you can't and you use message
    : passing. I can point to failures with both models.

    Ron and I have been having this argument for years, I used to be a
    believer, enough that I got him a pile of Sun hardware years ago to work
    on this.

    I'm not a believer in DSM anymore, through no fault on Ron's part.
    Ron did some really cool stuff in the DSM area and he has pushed the
    limits of what you can do there (though I'm not real clear if anything
    ever happened as a result of all those discussions about release
    consistency; Ron?)

    Anyway, the big problem with DSM is performance and the real problem is
    that there isn't a good answer. The DSM advocates all love to tell you
    about how it solves problems, porting is easier, computers are cheaper
    than people, etc. But that's all nonsense if the model takes a 200
    CPU system and makes it perform like a 20 CPU SMP. Obviously, if that
    were the case, people would just buy the SMP, it's cheaper and faster.
    So while the DSM crowd will tell you otherwise, there are definite,
    quantifiable limits about where it stops making sense.

    As far as I can tell, those limits are all in the performance area.
    If that's true, DSM is really only useful if it lives up to both the ease
    of use and the performance promise. Not only does it not, but it can't.
    Here's why: in order to get good performance, contended memory needs to
    be released as soon as possible so the next guy can use it. There's the
    bummer. Only the application knows when it is done with a chunk of
    memory, the OS can't know, it has know why of getting that knowledge.
    So the obvious answer is to make the application tell the OS (or DSM
    manager, whatever) that it is done. An operation becomes

    lock();
    do some work
    unlock();

    and we need to modify the unlock to tell the OS that the memory that was
    just worked on is available. This is where the release consistency comes
    in, you could have lock primitives that are like

    cookie = lock(address, length);
    do some work;
    unlock(cookie);

    and the unlock could tell the DSM manager. Seems pretty nice, eh? At
    first blush, that's what I thought too. But it all falls apart in the
    real world. In the real world, granularity kills this model. What if
    what you want to lock is a linked list, with chunks of the list all over
    memory? Doesn't work so well, does it?

    In the end, the crucial observation is that a DSM depends 100% on the
    application telling it that the memory is "released" and someone else
    can use it. It's a boundry that only the app knows.

    The problem is that this breaks the ease of use claim. You now have
    to go through all your apps and teach them about the new memory model.
    Yuck. It's much easier to have them just pass messages, the boundries
    are unambiguous.

    All the DSM people can yell all they want, but we have 10-20 years of
    research in this area and so far, nothing has shown any significant
    results.

    Conclusion: if you like DSM, that's fine, but be aware that many have
    tried and all have failed. And above all, don't expect your DSM stuff
    to be a welcome addition to the kernel until it has moved out of the
    research project stage. Linux, God bless it, is not a research project,
    people run their businesses on it.

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

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