[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1708312050040.2346@nanos>
Date: Thu, 31 Aug 2017 20:53:56 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Frederic Weisbecker <fweisbec@...il.com>
cc: Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
Chris Metcalf <cmetcalf@...lanox.com>,
Luiz Capitulino <lcapitulino@...hat.com>,
Christoph Lameter <cl@...ux.com>,
"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
Ingo Molnar <mingo@...nel.org>, Mike Galbraith <efault@....de>,
Rik van Riel <riel@...hat.com>,
Wanpeng Li <kernellwp@...il.com>
Subject: Re: [RFC PATCH 12/12] housekeeping: Reimplement isolcpus on
housekeeping
On Mon, 28 Aug 2017, Frederic Weisbecker wrote:
> On Mon, Aug 28, 2017 at 06:24:16PM +0200, Peter Zijlstra wrote:
> > On Mon, Aug 28, 2017 at 05:27:15PM +0200, Frederic Weisbecker wrote:
> > > Although for example I guess (IIUC) that if you create an unbound
> > > timer on a NULL domain, it will be stuck on it for ever as we can't
> > > walk any hierarchy from the current CPU domain.
> >
> > Not sure what you're on about. Timers have their own hierarchy.
>
> Check out get_nohz_timer_target() which relies on scheduler hierarchies to
> look up a CPU to enqueue an unpinned timer on.
Which is one of the most idiotic things we have in that code
path. Anna-Maria has posted this series which gets rid of that nonsense, by
queueing the timer on the current cpu into a wheel, which gets pulled in by
others. That makes a lot of sense because most of these timers get canceled
before expiry anyway. But we still need to fix the fallout and the few
corner cases to make that work reliably. We'll do that hopefully sooner
than later.
Thanks,
tglx
Powered by blists - more mailing lists