[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55C3959E.9050405@ezchip.com>
Date: Thu, 6 Aug 2015 13:13:02 -0400
From: Chris Metcalf <cmetcalf@...hip.com>
To: Frederic Weisbecker <fweisbec@...il.com>,
Peter Zijlstra <peterz@...radead.org>
CC: LKML <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
Christoph Lameter <cl@...ux.com>,
Ingo Molnar <mingo@...nel.org>,
Viresh Kumar <viresh.kumar@...aro.org>,
Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH 08/10] posix-cpu-timers: Migrate to use new tick
dependency mask model
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists