Re: [PATCH 08/10] posix-cpu-timers: Migrate to use new tick dependency mask model
From: Chris Metcalf
Date: Thu Aug 06 2015 - 13:13:22 EST
On 8/3/2015 1:39 PM, Frederic Weisbecker wrote:
On Mon, Aug 03, 2015 at 07:12:43PM +0200, Peter Zijlstra wrote:
On Fri, Jul 31, 2015 at 04:49:55PM +0200, Frederic Weisbecker wrote:
Instead of doing a per signal dependency, I'm going to use a per task
one.
Urgh, does this mean you'll keep the horrid tick_nohz_task_switch()
thing?
This current patchset removed the need for that with a global dependency
for posix timers: as long as there is one enqueued we keep the tick. But
Chris and Luiz fear that Tilera users have posix timers on housekeepers.
I think Luiz was representing a different class of users, not Tilera ones, FWIW.
But you need to periodically poll on timer expiration from a housekeeper.
It's not only about firing the timer, it's about elapsing it against the
target cputime.
Oh right, that makes sense. Layering this on top of the existing offlining patches that
you mentioned sounds like it will get us close to what we want, though.
Another thing: now I recall why I turned posix timers to a global tick dependency.
In case of a per task/process dependency we still need the context switch hook because
if we enqueue a timer to a sleeping task, the tick must be restarted when the task wakes
up. And that requires a check on context switch.
Another approach might be to separately track nohz_full and housekeeping states, and then
add a hook at task migration time. This is presumably much less frequent than context switch,
and would allow re-assessing this kind of state when moving a task from housekeeping to
nohz_full or vice versa. Then a global tick dependency would be OK when a thread was running
on a nohz_full core (because frankly, that's just stupid, and you get what's coming to you),
but for housekeeping cores we could avoid having to worry about it. (I admit this idea is
half-baked but maybe it will inspire further baking.)
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/