Re: [PATCH 0/6] support "dataplane" mode for nohz_full

On Sat, May 9, 2015 at 12:05 AM, Ingo Molnar [off-list ref] wrote:

* Andrew Morton [off-list ref] wrote:

quoted

On Fri, 8 May 2015 19:11:10 -0400 Chris Metcalf [off-list ref] wrote:

quoted

On 5/8/2015 5:22 PM, Steven Rostedt wrote:

quoted

On Fri, 8 May 2015 14:18:24 -0700
Andrew Morton [off-list ref] wrote:

quoted

On Fri, 8 May 2015 13:58:41 -0400 Chris Metcalf [off-list ref] wrote:

quoted

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.

quoted

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