lkml.org 
[lkml]   [2004]   [Oct]   [7]   [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
> On Thu, 7 Oct 2004, Paul Jackson wrote:
>
>> > I don't see what non-exclusive cpusets buys us.
>>
>> One can nest them, overlap them, and duplicate them ;)
>
> I would also add, if the decision comes to make 'real exclusive' cpusets,
> my previous example, as a use for non-exclusive cpusets:
>
> we are running jobs that need to be 'mostly' isolated on some part of the
> system, and run in a specific location. We use cpusets for that. But we
> can't afford to dedicate a part of the system for administrative tasks
> (daemons, init..). These tasks should not be put inside one of the
> 'exclusive' cpusets, even temporary : they do not belong there. They
> should just be allowed to steal a few cpu cycles from time to time : non
> exclusive cpusets are the way to go.

That makes no sense to me whatsoever, I'm afraid. Why if they were allowed
"to steal a few cycles" are they so fervently banned from being in there?
You can keep them out of your userspace management part if you want.

So we have the purely exclusive stuff, which needs kernel support in the form
of sched_domains alterations. The rest of cpusets is just poking and prodding
at cpus_allowed, the membind API, and the irq binding stuff. All of which
you could do from userspace, without any further kernel support, right?
Or am I missing something?

M.


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