Re: [RFC/PATCH 0/4] CPUSET driven CPU isolation

[Paul Jackson <pj@sgi.com>]

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