From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1946290Ab2LFSB7 (ORCPT ); Thu, 6 Dec 2012 13:01:59 -0500 Received: from mail-pa0-f46.google.com ([209.85.220.46]:35713 "EHLO mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423025Ab2LFSB5 (ORCPT ); Thu, 6 Dec 2012 13:01:57 -0500 Date: Thu, 6 Dec 2012 10:01:50 -0800 From: Tejun Heo To: Jeff Moyer Cc: Jens Axboe , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Zach Brown , Peter Zijlstra , Ingo Subject: Re: [patch,v2] bdi: add a user-tunable cpu_list for the bdi flusher threads Message-ID: <20121206180150.GQ19802@htj.dyndns.org> References: <50BE5988.3050501@fusionio.com> <50BE5C99.6070703@fusionio.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Tue, Dec 04, 2012 at 05:26:26PM -0500, Jeff Moyer wrote: > I think it's a bit more involved than that. If you look at > kthread_create_on_node, the node portion only applies to where the > memory comes from, it says nothing of scheduling. To whit: > > /* > * root may have changed our (kthreadd's) priority or CPU mask. > * The kernel thread should not inherit these properties. > */ > sched_setscheduler_nocheck(create.result, SCHED_NORMAL, ¶m); > set_cpus_allowed_ptr(create.result, cpu_all_mask); > > So, if I were to make the change you suggested, I would be modifying the > existing behaviour. The way things stand, I think > kthread_create_on_node violates the principal of least surprise. ;-) I > would prefer a variant that affected scheduling behaviour as well as > memory placement. Tejun, Peter, Ingo, what are your opinions? Hmmm... cpu binding usually is done by kthread_bind() or explicit set_cpus_allowed_ptr() by the kthread itself. The node part of the API was added later because there was no way to control where the stack is allocated and we often ended up with kthreads which are bound to a CPU with stack on a remote node. I don't know. @node usually controls memory allocation and it could be surprising for it to control cpu binding, especially because most kthreads which are bound to CPU[s] require explicit affinity management as CPUs go up and down. I don't know. Maybe I'm just too used to the existing interface. As for the original patch, I think it's a bit too much to expose to userland. It's probably a good idea to bind the flusher to the local node but do we really need to expose an interface to let userland control the affinity directly? Do we actually have a use case at hand? Thanks. -- tejun