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

David Rientjes
2008-02-28T23:01:58Z

On Thu, 28 Feb 2008, Paul Jackson wrote:

> > How about moving watchdog/0 to a cpuset with exclusive access to only cpu
> > 1?
>
> I don't understand your question here.
>

Move the watchdog/0 thread to a cpuset that doesn't have access to cpu 0.

> > > + 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.)
>

Same situation occurs for a task bound to a cpuset that issues a
sched_setaffinity() call to restrict its cpumask further. There's nothing
new there.

> 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?
>

I'd hesitate to do that unless you can guarantee that restricting
kthreads mems_allowed via the cpuset interface won't cause any problems
either. Is there a benefit to reducing the size of a kthread's
mems_allowed that doesn't have an adverse effect on the kernel? What
about kswapd?

> 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.
>

You can move them, but you cannot reduce the size of the thread's
cpus_allowed since it was bound to a specific cpu via kthread_bind(). The
change to set_cpus_allowed() simply prevents this from happening in the
kernel as opposed to just stopping the possibility through cpusets.

> > 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 ;)?
>

Sure.