lkml.org 
[lkml]   [2004]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement
    Peter writes:
    >
    > I say this because,
    > strictly speaking and as you imply, the current affinity mechanism is
    > sufficient to provide that isolation BUT it would be a huge pain to
    > implement.

    The affects on any given task - where it gets scheduled and where it
    allocates memory - can be duplicated using the current affinity
    mechanisms (setaffinity/mbind/mempolicy).

    However the system wide naming of cpusets, the control of their access,
    use and modification, the exclusive rights to a CPU or Memory and the
    robust linkage of tasks to these named cpusets are, in my view, just the
    sort of system wide resource synchronization that kernels are born to
    do, and these capabilities are not provided by the per-task existing
    affinity mechanisms.

    However, my point doesn't matter much. Whether its a huge pain, or an
    infinite pain, so long as we agree it's more painful than we can
    tolerate, that's enough agreement to continue this discussion along
    other more fruitful lines.

    --
    I won't rest till it's the best ...
    Programmer, Linux Scalability
    Paul Jackson <pj@sgi.com> 1.650.933.1373
    -
    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 14:06    [W:4.115 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site