[lkml]   [2007]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 2/2] cpusets: add interleave_over_allowed option
    David wrote:
    > If we can't identify any applications that would be broken by this, what's
    > the difference in simply implementing Choice B and then, if we hear
    > complaints, add your hack to revert back to Choice A behavior based on the
    > get_mempolicy() call you specified is always part of libnuma?

    I'll probably reply to other parts of your message later, but this
    one catches my eye right now.

    "if we hear complaints, add your hack ... back" -- this doesn't seem
    like a good idea to me. Maybe inside Google you don't see it, but
    for those of us shipping computer systems using major distributions
    such as SUSE or Red Hat, there can be a year lag between when I send a
    feature patch to Andrew, and when my customers send their first
    feedback to me resulting from using that new feature.

    There are ways to expedite fixes for specific situations, of course,
    but in general, this is rather like sending out a deep space probe.
    You have to conservatively cover your options pre-launch, because
    post-launch repairs are costly, slow and limited.

    I won't rest till it's the best ...
    Programmer, Linux Scalability
    Paul Jackson <> 1.925.600.0401
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-10-29 06:49    [W:0.022 / U:6.900 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site