Thread (29 messages) flat view 29 messages, 7 authors, 2016-07-05

Re: [PATCH v9 04/13] task_isolation: add initial support

From: Christoph Lameter <hidden>
Date: 2016-07-05 17:55:44
Also in: lkml

On Tue, 5 Jul 2016, Frederic Weisbecker wrote:
quoted
quoted
quoted
That's true, but I'd argue the behavior in that case should be that you can
raise that kind of exception validly (so you can debug), and then you should
quiesce on return to userspace so the application doesn't see additional
exceptions.
I don't see how we can quiesce such things.
I'm imagining task A is in dataplane mode, and task B wants to debug
it by writing a breakpoint into its text.  When task A hits the
breakpoint, it will enter the kernel, and hold there while task B
pokes at it with ptrace.  When task A finally is allowed to return to
userspace, it should quiesce before entering userspace in case any
timer interrupts got scheduled (again, maybe due to softirqs or
whatever, or random other kernel activity targeting that core while it
was in the kernel, or whatever).  This is just the same kind of
quiescing we do on return from the initial prctl().
Well again I think it shouldn't happen. Quiescing should be done once
and for all.
For debugging something like that would be helpful. And yes for the
realtime use cases quiescing is once and for all (until we end a different
operation mode if requested by the app)

quoted
quoted
quoted
- Soft mode (I don't think we want this) - like "no signal" except you don't even quiesce
  on return to userspace, and asynchronous interrupts don't even cause a signal.
  It's basically "best effort", just nohz_full plus the code that tries to get things
  like LRU or vmstat to run before returning to userspace.  I think there isn't enough
  "value add" to make this a separate mode, though.
I can imagine HPC to be willing this mode.
Yes, perhaps.  I'm not convinced we want to target HPC without a much
clearer sense of why this is better than nohz_full, though.  I fear
people might think "task isolation" is better by definition and not
think too much about it, but I'm really not sure it is better for the
HPC use case, necessarily.
HPC folks generally like to actually understand what is going on in order
to get the best performance. Just expose the knobs for us please.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help