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.