[lkml]   [1999]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Lets get this right (WAS RE:MOSIX and kernel mods)
    From "Albert D. Cahalan" <>
    : No, just the person I responded to. He made an emotional appeal based
    : on some kind of glorious fight against mediocrity.

    Yes, and you made an emotional appeal, also not backed up with any facts,
    for some features that are of very questionable usefulness. Based on my
    own direct experience with DSM, as well as having reviewed multiple DSM
    papers, including a Stanford PhD thesis, and having read piles of other
    DSM papers, and having worked on applications which actually use DSM,
    I concur with the conclusion that the former person made: DSM sucks.

    And it isn't an emotional thing at all, it's simply that it doesn't work
    for any real applications. Any application which can withstand the
    latencies introduced by DSM can typically be trivially rewritten to
    use MPI or PVM intrerfaces to accomplish the same thing, usually with
    higher performance.

    : Those that wrote the DSM code state that it has little impact on the
    : rest of the kernel. Do you claim that they lie?

    Yup, I sure do. And I also question the addition of a feature which has
    been repeatedly shown to cause more problems than it solves. If you
    really want DSM in the kernel, then put it into fs/dsm file system,
    use mmap to create the shared memory, and extend msync() to handle your
    coherency. This has been done before, using NFS as a base, and I have
    a paper I can send you on it. At least that way, while you are learning
    about what a bad idea this is, you are doing it in your own file system,
    which is a nice self contained sandbox. If you make it work, great.
    If you don't, also great because you haven't added a bunch of stuff to
    the generic kernel in the process.

    Even if this was a great idea, I'd ask you to do it this way - it is the
    obvious right way of doing it. In fact, SunOS's VM system to file system
    interface was carefully designed to allow exactly this sort of coherency
    decisions to be done in the file system, not in the VM system. The VM
    system presented an abstraction which did not include a coherency protocol
    or guarentee. That was a property of the file system. As it should be.

    : > Show me the apps which match this model.
    : Just about any shared memory app fits, given the right run length,

    Once again, show me the apps. Specific apps, show me the code to those
    apps and tell me why you /know/, not why you /think/, those apps will
    work on a slow DSM substrate.

    Telling us that you think this will work is not very credible, especially
    when you are talking to someone who is (a) a performance guy, (b) a
    file systems and VM guy, (c) has worked in this area, and (d) has read
    a bizillion papers on the topic, all of which eventually conclude that
    it is a bad idea.

    It would be a lot different if it were just my opinion against your
    opinion, that's just two idiots arguing, to coin a phrase. So far,
    this appears to be my experience against your opinion, which leaves
    you in a shaky position. I'm more than happy to be proven wrong, that
    would mean that I have learned something which is always a welcome event.
    But I'm convinced through multiple experiences that it is unlikely that
    you can prove me wrong, so I'm asking you to actually do so instead of
    just asserting that you can. I hope that you take this the right way -
    I want to be surprised, but given the track record of DSM, the right
    thing here is to push back very hard and request real hard facts rather
    than theories.

    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:50    [W:0.022 / U:36.140 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site