From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753743AbbEIHTb (ORCPT ); Sat, 9 May 2015 03:19:31 -0400 Received: from mail-la0-f41.google.com ([209.85.215.41]:32942 "EHLO mail-la0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753512AbbEIHT2 (ORCPT ); Sat, 9 May 2015 03:19:28 -0400 MIME-Version: 1.0 In-Reply-To: <20150509070538.GA9413@gmail.com> References: <1431107927-13998-1-git-send-email-cmetcalf@ezchip.com> <20150508141824.797eb0d89d514e39fd30fffe@linux-foundation.org> <20150508172210.559830a9@gandalf.local.home> <554D428E.6020702@ezchip.com> <20150508161909.308d60e21f6b83b897174276@linux-foundation.org> <20150509070538.GA9413@gmail.com> From: Andy Lutomirski Date: Sat, 9 May 2015 00:19:05 -0700 Message-ID: Subject: Re: [PATCH 0/6] support "dataplane" mode for nohz_full To: Ingo Molnar Cc: Andrew Morton , Chris Metcalf , Steven Rostedt , Gilad Ben Yossef , Ingo Molnar , Peter Zijlstra , Rik van Riel , Tejun Heo , Frederic Weisbecker , Thomas Gleixner , "Paul E. McKenney" , Christoph Lameter , "Srivatsa S. Bhat" , "linux-doc@vger.kernel.org" , Linux API , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 9, 2015 at 12:05 AM, Ingo Molnar wrote: > > * Andrew Morton wrote: > >> On Fri, 8 May 2015 19:11:10 -0400 Chris Metcalf wrote: >> >> > On 5/8/2015 5:22 PM, Steven Rostedt wrote: >> > > On Fri, 8 May 2015 14:18:24 -0700 >> > > Andrew Morton wrote: >> > > >> > >> On Fri, 8 May 2015 13:58:41 -0400 Chris Metcalf wrote: >> > >> >> > >>> A prctl() option (PR_SET_DATAPLANE) is added >> > >> Dumb question: what does the term "dataplane" mean in this context? I >> > >> can't see the relationship between those words and what this patch >> > >> does. >> > > I was thinking the same thing. I haven't gotten around to searching >> > > DATAPLANE yet. >> > > >> > > I would assume we want a name that is more meaningful for what is >> > > happening. >> > >> > The text in the commit message and the 0/6 cover letter do try to explain >> > the concept. The terminology comes, I think, from networking line cards, >> > where the "dataplane" is the part of the application that handles all the >> > fast path processing of network packets, and the "control plane" is the part >> > that handles routing updates, etc., generally slow-path stuff. I've probably >> > just been using the terms so long they seem normal to me. >> > >> > That said, what would be clearer? NO_HZ_STRICT as a superset of >> > NO_HZ_FULL? Or move away from the NO_HZ terminology a bit; after all, >> > we're talking about no interrupts of any kind, and maybe NO_HZ is too >> > limited in scope? So, NO_INTERRUPTS? USERSPACE_ONLY? Or look >> > to vendors who ship bare-metal runtimes and call it BARE_METAL? >> > Borrow the Tilera marketing name and call it ZERO_OVERHEAD? >> > >> > Maybe BARE_METAL seems most plausible -- after DATAPLANE, to me, >> > of course :-) > > 'baremetal' has uses in virtualization speak, so I think that would be > confusing. > >> I like NO_INTERRUPTS. Simple, direct. > > NO_HZ_PURE? > Naming aside, I don't think this should be a per-task flag at all. We already have way too much overhead per syscall in nohz mode, and it would be nice to get the per-syscall overhead as low as possible. We should strive, for all tasks, to keep syscall overhead down *and* avoid as many interrupts as possible. That being said, I do see a legitimate use for a way to tell the kernel "I'm going to run in userspace for a long time; stay away". But shouldn't that be a single operation, not an ongoing flag? IOW, I think that we should have a new syscall quiesce() or something rather than a prctl. --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH 0/6] support "dataplane" mode for nohz_full Date: Sat, 9 May 2015 00:19:05 -0700 Message-ID: References: <1431107927-13998-1-git-send-email-cmetcalf@ezchip.com> <20150508141824.797eb0d89d514e39fd30fffe@linux-foundation.org> <20150508172210.559830a9@gandalf.local.home> <554D428E.6020702@ezchip.com> <20150508161909.308d60e21f6b83b897174276@linux-foundation.org> <20150509070538.GA9413@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <20150509070538.GA9413-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Ingo Molnar Cc: Andrew Morton , Chris Metcalf , Steven Rostedt , Gilad Ben Yossef , Ingo Molnar , Peter Zijlstra , Rik van Riel , Tejun Heo , Frederic Weisbecker , Thomas Gleixner , "Paul E. McKenney" , Christoph Lameter , "Srivatsa S. Bhat" , "linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Linux API , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-api@vger.kernel.org On Sat, May 9, 2015 at 12:05 AM, Ingo Molnar wrote: > > * Andrew Morton wrote: > >> On Fri, 8 May 2015 19:11:10 -0400 Chris Metcalf wrote: >> >> > On 5/8/2015 5:22 PM, Steven Rostedt wrote: >> > > On Fri, 8 May 2015 14:18:24 -0700 >> > > Andrew Morton wrote: >> > > >> > >> On Fri, 8 May 2015 13:58:41 -0400 Chris Metcalf wrote: >> > >> >> > >>> A prctl() option (PR_SET_DATAPLANE) is added >> > >> Dumb question: what does the term "dataplane" mean in this context? I >> > >> can't see the relationship between those words and what this patch >> > >> does. >> > > I was thinking the same thing. I haven't gotten around to searching >> > > DATAPLANE yet. >> > > >> > > I would assume we want a name that is more meaningful for what is >> > > happening. >> > >> > The text in the commit message and the 0/6 cover letter do try to explain >> > the concept. The terminology comes, I think, from networking line cards, >> > where the "dataplane" is the part of the application that handles all the >> > fast path processing of network packets, and the "control plane" is the part >> > that handles routing updates, etc., generally slow-path stuff. I've probably >> > just been using the terms so long they seem normal to me. >> > >> > That said, what would be clearer? NO_HZ_STRICT as a superset of >> > NO_HZ_FULL? Or move away from the NO_HZ terminology a bit; after all, >> > we're talking about no interrupts of any kind, and maybe NO_HZ is too >> > limited in scope? So, NO_INTERRUPTS? USERSPACE_ONLY? Or look >> > to vendors who ship bare-metal runtimes and call it BARE_METAL? >> > Borrow the Tilera marketing name and call it ZERO_OVERHEAD? >> > >> > Maybe BARE_METAL seems most plausible -- after DATAPLANE, to me, >> > of course :-) > > 'baremetal' has uses in virtualization speak, so I think that would be > confusing. > >> I like NO_INTERRUPTS. Simple, direct. > > NO_HZ_PURE? > Naming aside, I don't think this should be a per-task flag at all. We already have way too much overhead per syscall in nohz mode, and it would be nice to get the per-syscall overhead as low as possible. We should strive, for all tasks, to keep syscall overhead down *and* avoid as many interrupts as possible. That being said, I do see a legitimate use for a way to tell the kernel "I'm going to run in userspace for a long time; stay away". But shouldn't that be a single operation, not an ongoing flag? IOW, I think that we should have a new syscall quiesce() or something rather than a prctl. --Andy