LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Paul Jackson <pj@sgi.com>
Cc: mingo@elte.hu, a.p.zijlstra@chello.nl, tglx@linutronix.de,
oleg@tv-sign.ru, rostedt@goodmis.org, maxk@qualcomm.com,
linux-kernel@vger.kernel.org
Subject: Re: [RFC/PATCH 0/4] CPUSET driven CPU isolation
Date: Thu, 28 Feb 2008 15:00:37 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.1.00.0802281452340.13082@chino.kir.corp.google.com> (raw)
In-Reply-To: <20080228164637.114fb19d.pj@sgi.com>
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.
next prev parent reply other threads:[~2008-02-28 23:01 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-27 22:21 Peter Zijlstra
2008-02-27 22:21 ` [RFC/PATCH 1/4] sched: remove isolcpus Peter Zijlstra
2008-02-27 23:57 ` Max Krasnyanskiy
2008-02-28 10:19 ` Peter Zijlstra
2008-02-28 19:36 ` Max Krasnyansky
2008-02-27 22:21 ` [RFC/PATCH 2/4] cpuset: system sets Peter Zijlstra
2008-02-27 23:39 ` Paul Jackson
2008-02-28 1:53 ` Max Krasnyanskiy
2008-02-27 23:52 ` Max Krasnyanskiy
2008-02-28 0:11 ` Paul Jackson
2008-02-28 0:29 ` Steven Rostedt
2008-02-28 1:45 ` Max Krasnyanskiy
2008-02-28 3:41 ` Steven Rostedt
2008-02-28 4:58 ` Max Krasnyansky
2008-02-27 22:21 ` [RFC/PATCH 3/4] genirq: system set irq affinities Peter Zijlstra
2008-02-28 0:10 ` Max Krasnyanskiy
2008-02-28 10:19 ` Peter Zijlstra
2008-02-27 22:21 ` [RFC/PATCH 4/4] kthread: system set kthread affinities Peter Zijlstra
2008-02-27 23:38 ` [RFC/PATCH 0/4] CPUSET driven CPU isolation Max Krasnyanskiy
2008-02-28 10:19 ` Peter Zijlstra
2008-02-28 17:33 ` Max Krasnyanskiy
2008-02-28 7:50 ` Ingo Molnar
2008-02-28 8:08 ` Paul Jackson
2008-02-28 9:08 ` Ingo Molnar
2008-02-28 9:17 ` Paul Jackson
2008-02-28 9:32 ` David Rientjes
2008-02-28 10:12 ` David Rientjes
2008-02-28 10:26 ` Peter Zijlstra
2008-02-28 17:37 ` Paul Jackson
2008-02-28 21:24 ` David Rientjes
2008-02-28 22:46 ` Paul Jackson
2008-02-28 23:00 ` David Rientjes [this message]
2008-02-29 0:16 ` Paul Jackson
2008-02-29 1:05 ` David Rientjes
2008-02-29 3:34 ` Paul Jackson
2008-02-29 4:00 ` David Rientjes
2008-02-29 6:53 ` Paul Jackson
2008-02-28 10:46 ` Ingo Molnar
2008-02-28 17:47 ` Paul Jackson
2008-02-28 20:11 ` Max Krasnyansky
2008-02-28 20:13 ` Paul Jackson
2008-02-28 20:26 ` Max Krasnyansky
2008-02-28 20:27 ` Paul Jackson
2008-02-28 20:45 ` Max Krasnyansky
2008-02-28 20:23 ` Max Krasnyansky
2008-02-28 17:48 ` Max Krasnyanskiy
2008-02-29 8:31 ` Andrew Morton
2008-02-29 8:36 ` Andrew Morton
2008-02-29 9:10 ` Ingo Molnar
2008-02-29 18:06 ` Max Krasnyanskiy
2008-02-28 12:12 ` Mark Hounschell
2008-02-28 19:57 ` Max Krasnyansky
2008-02-29 18:55 ` [RFC/PATCH] cpuset: cpuset irq affinities Peter Zijlstra
2008-02-29 19:02 ` Ingo Molnar
2008-02-29 20:52 ` Max Krasnyanskiy
2008-02-29 21:03 ` Peter Zijlstra
2008-02-29 21:20 ` Max Krasnyanskiy
2008-03-03 11:57 ` Peter Zijlstra
2008-03-03 17:36 ` Paul Jackson
2008-03-03 17:57 ` Peter Zijlstra
2008-03-03 18:10 ` Paul Jackson
2008-03-03 18:18 ` Peter Zijlstra
2008-03-04 7:35 ` Paul Jackson
2008-03-04 11:06 ` Peter Zijlstra
2008-03-04 19:52 ` Max Krasnyanskiy
2008-03-05 1:11 ` Paul Jackson
2008-03-05 8:37 ` Peter Zijlstra
2008-03-05 8:50 ` Ingo Molnar
2008-03-05 12:35 ` Paul Jackson
2008-03-05 12:43 ` Ingo Molnar
2008-03-05 17:44 ` Paul Jackson
2008-03-05 19:17 ` Max Krasnyansky
2008-03-06 13:47 ` Paul Jackson
2008-03-06 15:21 ` Peter Zijlstra
2008-03-07 3:40 ` Paul Jackson
2008-03-07 6:39 ` Paul Jackson
2008-03-07 8:47 ` Paul Menage
2008-03-07 14:57 ` Paul Jackson
2008-03-03 18:41 ` Paul Menage
2008-03-03 18:52 ` Paul Jackson
2008-03-04 5:26 ` Paul Menage
2008-03-04 6:15 ` Paul Jackson
2008-03-04 6:21 ` Paul Menage
2008-03-04 6:26 ` Paul Jackson
2008-03-04 6:34 ` Paul Menage
2008-03-04 6:51 ` Paul Jackson
2008-02-29 20:55 ` Paul Jackson
2008-02-29 21:14 ` Peter Zijlstra
2008-02-29 21:29 ` Ingo Molnar
2008-02-29 21:32 ` Ingo Molnar
2008-02-29 21:42 ` Max Krasnyanskiy
2008-02-29 22:00 ` Paul Jackson
2008-02-29 21:53 ` Paul Jackson
2008-03-02 5:18 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.1.00.0802281452340.13082@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=a.p.zijlstra@chello.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=maxk@qualcomm.com \
--cc=mingo@elte.hu \
--cc=oleg@tv-sign.ru \
--cc=pj@sgi.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--subject='Re: [RFC/PATCH 0/4] CPUSET driven CPU isolation' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).