Re: [PATCH v7 07/11] arch/x86: enable task isolation functionality

[Chris Metcalf <cmetcalf@ezchip.com>]

On 09/30/2015 04:25 PM, Thomas Gleixner wrote:
> On Tue, 29 Sep 2015, Andy Lutomirski wrote:
>> On Tue, Sep 29, 2015 at 10:42 AM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
>>> I suppose if your hardware supported it, you could imagine
>>> a mode where userspace can request an alarm a specific
>>> amount of time in the future, and the task isolation code
>>> would then ignore an alarm that was going off at that
>>> specific time.
> Ignore in what way?

So the model for task isolation, as proposed, is that you are
NOT trying to use kernel services, because the overheads are
too great.  The typical example is that you are running a
userspace packet-processing application, and entering the
kernel for pretty much any reason will cause your thread to
drop packets all over the floor.  So, we ensure that you never
enter the kernel asynchronously.

Now obviously if the task needs to enter the kernel, you have
to allow it do so, and in fact there will be plenty of scenarios
where that's exactly what you want to do; but for example you
may have a way to register that a particular thread is opting out
of packet processing for the moment, and it will instead go
off and use the kernel to log some kind of information about
some exceptional packet flow, or some debugging state about
its own internals, or whatever.  At that moment you would like
the thread to be able to use arbitrary kernel facilities in a
relatively transparent way.

However, when it is done using the kernel and returns to
userspace and signs up to handle packets again, you REALLY
don't want to encounter some kind of tailing off of timer
interrupts while some kernel subsystem quiesces or whatever.
So we would like to spin in the kernel until no further timer
interrupts are queued.  In the original tile implementation,
we would just wait until the timer interrupt was masked,
which guaranteed it wouldn't fire again; for a more portable
approach in the task-isolation patch series, I'm testing
that the tick_cpu_device has next_event set to KTIME_MAX.

The discussion in this email thread is that maybe it might
make sense for one of these userspace driver threads to
request a SIGALARM in 10 minutes, and then you'd assume
it was done very intentionally, and figure out a way to
discount that timer event somehow -- so you'd still return
to userspace if all that was pending was one timer interrupt
scheduled 10 minutes out, but if your hardware didn't
allow setting such a long timer, you wouldn't return early,
or if some other event was scheduled sooner, you wouldn't
return early, etc.  As I said in my previous email, this seems
like a total corner case and not worth worrying about now;
maybe in the future someone will want to think about it.

So for now, if a task-isolation thread sets up a timer,
they're screwed: so, don't do that.  And it's really not part of
the typical programming model for these kinds of userspace
drivers anyway, so it's pretty reasonable to forbid it.

-- 
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com