All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.