Messages in this thread | | | Date | Tue, 21 Dec 2010 02:24:20 +0100 | From | Frederic Weisbecker <> | Subject | Re: [RFC PATCH 15/15] nohz_task: Procfs interface |
| |
On Mon, Dec 20, 2010 at 05:16:39PM +0100, Peter Zijlstra wrote: > On Mon, 2010-12-20 at 16:57 +0100, Frederic Weisbecker wrote: > > > Should I? > > Well yes, this interface of explicitly marking a task and cpu as > task_no_hz is kinda restrictive and useless.
Yeah indeed. I did the mistake to focus on the HPC specific worflow, or rather what I imagine as the HPC specific workflow: a single task per cpu doing intensive work.
But this should also work without even tweaks on the affinity or so.
> When I run 4 cpu-bound tasks on a quad-core I shouldn't have to do > anything to benefit from this.
Yeah exactly. If the scheduler load balancer does the appropriate share between CPUs, having only one task running on each should happen often enough.
And let the user optimize that by playing with irq and task affinity.
We still need to do the echo 1 > /proc/pid/nohz though. > I don't see why having this cpumask is restricting you in any way, > user-space tasks don't migrate around, that all happens in kernel space.
The cpumask is useful to find unbound targets and for RCU to know if it should send the specific IPI. Ah and also to keep at least one CPU that has no nohz task to handle the timekeeping.
- For the unbound targets, we are discussing that elsewhere, that's one reason for which we need to keep a CPU without nohz task, so that it can handle those unbound timers. But if there is no such CPU, we can just fallback as we did before.
- RCU can unconditonally send the specific IPI which can fallback into executing the simple resched IPI callback if no nohz task is runnning on the CPU.
- The last reason to keep at least one CPU without nohz task is then the timekeeping. But again, if every CPU has a nohz task, we can fallback to a random one
> Also, I'm not quite happy with the pure userspace restriction, but at > least I see why you did that event though you didn't mention that.
What do you mean? The fact that kernel threads can not be nohz task?
| |