lkml.org 
[lkml]   [2008]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/PATCH 0/4] CPUSET driven CPU isolation
David wrote:
> How about moving watchdog/0 to a cpuset with exclusive access to only cpu
> 1?

I don't understand your question here.

> > + if (unlikely((p->flags & PF_CPU_BOUND) && p != current &&
> > + !cpus_subset(p->cpus_allowed, new_mask))) {
> > + ret = -EINVAL;
> >
>
> That's a convenient way for a kthread to temporarily expand its set of
> cpus_allowed and then never be able to remove the added cpus again. Do
> you have any examples in the tree where a kthread does this?

Good question. Actually, we -normally- have pinned tasks in the top cpuset,
where the top cpuset allows all CPUs, but the pinned task has a cpus_allowed
(in its task struct) of just one or a few CPUs (for node pinning.)

So ... could we allow moving pinned threads to any cpuset that allowed
the CPUs to which it was pinned (my cpus_subset() test, above), but
-not- change the pinned tasks cpus_allowed in its task struct, keeping
it pinned to just the same one or few CPUs?

> That's why the check in set_cpus_allowed() is
>
> cpus_equal(p->cpus_allowed, newmask)
>
> since it prevents PF_CPU_BOUND tasks from being moved out of the root
> cpuset.

I don't think that the cpus_equal() check prevents that (shrinking a
pinned tasks cpuset out from under it.) Try the following on a freshly
booted system with your proposed patch:

mkdir /dev/cpuset
mount -t cpuset cpuset /dev/cpuset
cd /dev/cpuset
mkdir a
cp ???s a
< tasks sed -un -e p -e 10q > a/tasks

I'll wager you just moved a few pinned tasks into cpuset 'a'. This
would be allowed, as 'a' has the same cpus as the top cpuset. But then
one could shrink a (if it had more than 1 CPU in the first place), leaving
some pinned tasks in a cpuset they weren't allowed to run in, essentially
unpinning them.

> PF_CPU_BOUND follows the nomenclature of kthread_bind() really well, but
> it could probably be confused with a processor-bound task. So perhaps
> PF_BOUND_CPU is even better?

Good point - "BOUND" as the past tense of "BIND". How about
PF_THREAD_BIND ;)?

--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.940.382.4214


\
 
 \ /
  Last update: 2008-02-28 23:49    [W:0.115 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site