> From: Andy Lutomirski [mailto:luto@xxxxxxxxxxxxxx] > 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@xxxxxxxxxxxxxxx; Andrew Morton; linux- > kernel@xxxxxxxxxxxxxxx; 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" <cmetcalf@xxxxxxxxxx> wrote: > > > > 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 ��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
