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.

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