Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965611AbbEMVA1 (ORCPT ); Wed, 13 May 2015 17:00:27 -0400 Received: from e38.co.us.ibm.com ([32.97.110.159]:37021 "EHLO e38.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965489AbbEMU6h (ORCPT ); Wed, 13 May 2015 16:58:37 -0400 Date: Wed, 13 May 2015 10:51:50 -0700 From: "Paul E. McKenney" To: Andy Lutomirski Cc: Ingo Molnar , Peter Zijlstra , Chris Metcalf , Gilad Ben Yossef , Steven Rostedt , Ingo Molnar , Andrew Morton , Rik van Riel , Tejun Heo , Thomas Gleixner , Frederic Weisbecker , Christoph Lameter , "Srivatsa S. Bhat" , "linux-doc@vger.kernel.org" , Linux API , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 4/6] nohz: support PR_DATAPLANE_QUIESCE Message-ID: <20150513175150.GL6776@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <1431107927-13998-1-git-send-email-cmetcalf@ezchip.com> <1431107927-13998-5-git-send-email-cmetcalf@ezchip.com> <20150512093349.GH21418@twins.programming.kicks-ass.net> <20150512095030.GD11477@gmail.com> <20150512103805.GJ21418@twins.programming.kicks-ass.net> <20150512125200.GB17244@gmail.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) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15051320-0029-0000-0000-000009C23077 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2333 Lines: 55 On Tue, May 12, 2015 at 09:35:25PM -0700, Andy Lutomirski wrote: > On Tue, May 12, 2015 at 5:52 AM, Ingo Molnar wrote: > > > > * Peter Zijlstra wrote: > > > >> > So if then a prctl() (or other system call) could be a shortcut > >> > to: > >> > > >> > - move the task to an isolated CPU > >> > - make sure there _is_ such an isolated domain available > >> > > >> > I.e. have some programmatic, kernel provided way for an > >> > application to be sure it's running in the right environment. > >> > Relying on random administration flags here and there won't cut > >> > it. > >> > >> No, we already have sched_setaffinity() and we should not duplicate > >> its ability to move tasks about. > > > > But sched_setaffinity() does not guarantee isolation - it's just a > > syscall to move a task to a set of CPUs, which might be isolated or > > not. > > > > What I suggested is that it might make sense to offer a system call, > > for example a sched_setparam() variant, that makes such guarantees. > > > > Say if user-space does: > > > > ret = sched_setscheduler(0, BIND_ISOLATED, &isolation_params); > > > > ... then we would get the task moved to an isolated domain and get a 0 > > return code if the kernel is able to do all that and if the current > > uid/namespace/etc. has the required permissions and such. > > > > ( BIND_ISOLATED will not replace the current p->policy value, so it's > > still possible to use the regular policies as well on top of this. ) > > I think we shouldn't have magic selection of an isolated domain. > Anyone using this has already configured some isolated CPUs and > probably wants to choose the CPU and, especially, NUMA node > themselves. Also, maybe it should be a special type of realtime > class/priority -- doing this should require RT permission IMO. I have no real argument against special permissions, but this feature is totally orthogonal to realtime classes/priorities. It is perfectly legitimate for a given CPU's single runnable task to be SCHED_OTHER, for example. Thanx, Paul -- 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/