RE: [PATCH 5/6] nohz: support PR_DATAPLANE_STRICT mode

From: Andy Lutomirski [mailto:luto@amacapital.net]
Sent: Saturday, May 09, 2015 10:29 AM
To: Chris Metcalf
Cc: Srivatsa S. Bhat; Paul E. McKenney; Frederic Weisbecker; Ingo Molnar;
Rik van Riel; linux-doc@vger.kernel.org; Andrew Morton; linux-
kernel@vger.kernel.org; Thomas Gleixner; Tejun Heo; Peter Zijlstra; Steven
Rostedt; Christoph Lameter; Gilad Ben Yossef; Linux API
Subject: Re: [PATCH 5/6] nohz: support PR_DATAPLANE_STRICT mode

On May 8, 2015 11:44 PM, "Chris Metcalf" [off-list ref] wrote:

quoted

With QUIESCE mode, the task is in principle guaranteed not to be
interrupted by the kernel, but only if it behaves.  In particular,
if it enters the kernel via system call, page fault, or any of
a number of other synchronous traps, it may be unexpectedly
exposed to long latencies.  Add a simple flag that puts the process
into a state where any such kernel entry is fatal.

To allow the state to be entered and exited, we add an internal
bit to current->dataplane_flags that is set when prctl() sets the
flags.  That way, when we are exiting the kernel after calling
prctl() to forbid future kernel exits, we don't get immediately
killed.

Is there any reason this can't already be addressed in userspace using
/proc/interrupts or perf_events?  ISTM the real goal here is to detect
when we screw up and fail to avoid an interrupt, and killing the task
seems like overkill to me.

Also, can we please stop further torturing the exit paths?  

So, I don't know if it is a practical suggestion or not, but would it better/easier to mark a pending signal on kernel entry for this case?
The upsides I see is that the user gets her notification (killing the task or just logging the event in a signal handler) and hopefully since return to userspace with a pending signal is already handled we don't need new code in the exit path?

Gilad