lkml.org 
[lkml]   [2004]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement
From
Date
On Tue, 2004-10-05 at 02:26, Simon Derr wrote:
> I'd like to present you at this point what was the original decision for
> having exclusive (called strict, at this point in history) and
> non-exclusive cpusets.
>
> The idea was to have a system, and run all jobs on it through a batch
> scheduler. Some jobs cared about performance, some didn't.
>
> The ones who cared about performance got an 'exclusive' cpuset, the ones
> who didn't got a 'non exclusive' cpuset.

It sounds to me (and please correct me if I'm wrong) like 'non
exclusive' cpusets are more like a convenient way to group tasks than
any sort of performance or scheduling imperative. It would seem what
we'd really want here is a task grouping functionality, more than a
'cpuset'. A cpuset seems a bit heavy handed if all we want to do group
tasks for ease of administration.


> There are still processes running outside the job cpusets (i.e in the root
> cpuset), sshd, the batch scheduler. These tasks use a low amount of CPU,
> so it is okay if they happen to run inside even 'exclusive' cpusets. For
> us, 'exclusive' only means that no other CPU-hungry job is going to share
> our CPU.

If that's all 'exclusive' means then 'exclusive' is a poor choice of
terminology. 'Exclusive' sounds like it would exclude all tasks it is
possible to exclude from running there (ie: with the exception of
certain necessary kernel threads).

-Matt

-
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:0.332 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site