Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753669AbYFJGq5 (ORCPT ); Tue, 10 Jun 2008 02:46:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751624AbYFJGqt (ORCPT ); Tue, 10 Jun 2008 02:46:49 -0400 Received: from bombadil.infradead.org ([18.85.46.34]:50790 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750946AbYFJGqt (ORCPT ); Tue, 10 Jun 2008 02:46:49 -0400 Subject: Re: [patch] sched: prevent bound kthreads from changing cpus_allowed From: Peter Zijlstra To: Max Krasnyanskiy Cc: David Rientjes , Paul Jackson , mingo@elte.hu, menage@google.com, linux-kernel@vger.kernel.org, Oleg Nesterov In-Reply-To: <484D99AD.4000306@qualcomm.com> References: <20080605152953.dcfefa47.pj@sgi.com> <484D99AD.4000306@qualcomm.com> Content-Type: text/plain Date: Tue, 10 Jun 2008 08:44:00 +0200 Message-Id: <1213080240.31518.5.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1821 Lines: 38 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(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/