[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140510004843.GB32393@localhost.localdomain>
Date: Sat, 10 May 2014 02:48:45 +0200
From: Frederic Weisbecker <fweisbec@...il.com>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Christoph Lameter <cl@...ux.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Gilad Ben-Yossef <gilad@...yossef.com>,
Tejun Heo <tj@...nel.org>, Mike Frysinger <vapier@...too.org>,
Minchan Kim <minchan.kim@...il.com>,
Hakan Akkan <hakanakkan@...il.com>,
Max Krasnyansky <maxk@...lcomm.com>,
LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
hughd@...gle.com, viresh.kumar@...aro.org,
Ingo Molnar <mingo@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
John Stultz <john.stultz@...aro.org>
Subject: Re: vmstat: On demand vmstat workers V4
On Fri, May 09, 2014 at 04:47:45PM -0700, Paul E. McKenney wrote:
> On Sat, May 10, 2014 at 12:57:15AM +0200, Thomas Gleixner wrote:
> If someone decides to make tick_do_timer_cpu non-constant in NO_HZ_FULL
> CPUs, they will break unless/until I make RCU deal with that sort
> of thing, at least for NO_HZ_FULL_SYSIDLE kernels. ;-)
>
> > We all know that we can do large scale overhauls in a very controlled
> > way if the need arises. But going for the most complex solution while
> > not knowing whether the least complex solution is feasible at all is
> > outright stupid or beyond.
> >
> > Unless someone comes up with a reasonable explantion for all of this I
> > put a general NAK on patches which are directed to kernel/time/*
> >
> > Correction:
> >
> > I'm taking patches right away which undo any damage which has been
> > applied w/o me noticing because I trusted the responsible developers /
> > maintainers.
> >
> > Preferrably those patches arrive before my return from LinuxCon Japan.
>
> I could easily have missed something, but as far as I know, there is
> nothing in the current kernel that allows tick_do_timer_cpu to move in
> NO_HZ_FULL kernels.
Right.
So we agree that housekeeping/timekeeping is going to stay CPU 0 for now.
But I still have the plan to make the timekeeper use the full sysidle
facility in order to adaptively get to dynticks idle.
Reminder for others: in NO_HZ_FULL, the timekeeper (always CPU 0) stays
completely periodic. It can't enter in dynticks idle mode because it
must maintain timekeeping on behalf of full dynticks CPUs. So that's
a power issue.
But Paul has a feature in RCU that lets us know when all CPUs are idle
and the timekeeper can finally sleep. Then when a full nohz CPU wakes
up from idle, it sends an IPI to the timekeeper if needed so the latter
restarts timekeeping maintainance.
It's not complicated to add to the timer code.
Most of the code is already there, in RCU, for a while already.
Are we keeping that direction?
--
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