linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Max Krasnyanskiy <maxk@qualcomm.com>
Cc: David Rientjes <rientjes@google.com>, Paul Jackson <pj@sgi.com>,
	mingo@elte.hu, menage@google.com, linux-kernel@vger.kernel.org,
	Oleg Nesterov <oleg@tv-sign.ru>
Subject: Re: [patch] sched: prevent bound kthreads from changing cpus_allowed
Date: Tue, 10 Jun 2008 08:44:00 +0200	[thread overview]
Message-ID: <1213080240.31518.5.camel@twins> (raw)
In-Reply-To: <484D99AD.4000306@qualcomm.com>

On Mon, 2008-06-09 at 13:59 -0700, Max Krasnyanskiy wrote:
> David Rientjes wrote:
> >>  2) Sometimes calls to kthread_bind are binding to any online cpu, such as in:
> >>
> >> 	drivers/infiniband/hw/ehca/ehca_irq.c:	kthread_bind(cct->task, any_online_cpu(cpu_online_map));
> >>
> >>     In such cases, the PF_THREAD_BOUND seems inappropriate.  The caller of
> >>     kthread_bind() really doesn't seem to care where that thread is bound;
> >>     they just want it on a CPU that is still online.
> >>
> > 
> > This particular case is simply moving the thread to any online cpu so that 
> > it survives long enough for the subsequent kthread_stop() in 
> > destroy_comp_task().  So I don't see a problem with this instance.
> > 
> > A caller to kthread_bind() can always remove PF_THREAD_BOUND itself upon 
> > return, but I haven't found any cases in the tree where that is currently 
> > necessary.  And doing that would defeat the semantics of kthread_bind() 
> > where these threads are supposed to be bound to a specific cpu and not 
> > allowed to run on others.
> 
> Actually I have another use case here. Above example in particular may be ok 
> but it does demonstrate the issue nicely. Which is that in some cases kthreads 
> are bound to a CPU but do not have a strict "must run here" requirement and 
> could be moved if needed.
> For example I need an ability to move workqueue threads. Workqueue threads do 
> kthread_bind().

Per cpu workqueues should stay on their cpu.

What you're really looking for is a more fine grained alternative to
flush_workqueue().


  parent reply	other threads:[~2008-06-10  6:46 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-05 19:57 [patch] sched: prevent bound kthreads from changing cpus_allowed David Rientjes
2008-06-05 20:29 ` Paul Jackson
2008-06-05 21:12   ` David Rientjes
2008-06-09 20:59     ` Max Krasnyanskiy
2008-06-09 22:07       ` David Rientjes
2008-06-10  4:23         ` Max Krasnyansky
2008-06-10 17:04           ` David Rientjes
2008-06-10 16:30         ` cpusets and kthreads, inconsistent behaviour Max Krasnyansky
2008-06-10 18:47           ` David Rientjes
2008-06-10 20:44             ` Max Krasnyansky
2008-06-10 20:54               ` David Rientjes
2008-06-10 21:15                 ` Max Krasnyansky
2008-06-10  6:44       ` Peter Zijlstra [this message]
2008-06-10 15:38         ` [patch] sched: prevent bound kthreads from changing cpus_allowed Max Krasnyansky
2008-06-10 17:00           ` Oleg Nesterov
2008-06-10 17:19             ` Peter Zijlstra
2008-06-10 20:24               ` workqueue cpu affinity Max Krasnyansky
2008-06-11  6:49                 ` Peter Zijlstra
2008-06-11 19:02                   ` Max Krasnyansky
2008-06-12 18:44                     ` Peter Zijlstra
2008-06-12 19:10                       ` Max Krasnyanskiy
2008-06-11 16:08                 ` Oleg Nesterov
2008-06-11 19:21                   ` Max Krasnyansky
2008-06-11 19:21                   ` Max Krasnyansky
2008-06-12 16:35                     ` Oleg Nesterov
2008-06-11 20:44                   ` Max Krasnyansky
2008-06-10 18:00             ` [patch] sched: prevent bound kthreads from changing cpus_allowed Max Krasnyansky
2008-06-05 20:52 ` Daniel Walker
2008-06-05 21:47 ` Paul Jackson
2008-06-10 10:28 ` Ingo Molnar
2008-06-10 17:47 ` Oleg Nesterov

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=1213080240.31518.5.camel@twins \
    --to=peterz@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxk@qualcomm.com \
    --cc=menage@google.com \
    --cc=mingo@elte.hu \
    --cc=oleg@tv-sign.ru \
    --cc=pj@sgi.com \
    --cc=rientjes@google.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).