On Sat, May 9, 2015 at 12:05 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > >> On Fri, 8 May 2015 19:11:10 -0400 Chris Metcalf <cmetcalf@xxxxxxxxxx> wrote: >> >> > On 5/8/2015 5:22 PM, Steven Rostedt wrote: >> > > On Fri, 8 May 2015 14:18:24 -0700 >> > > Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: >> > > >> > >> On Fri, 8 May 2015 13:58:41 -0400 Chris Metcalf <cmetcalf@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
