[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160624170421.GB1377@jtriplet-mobl2.jf.intel.com>
Date: Fri, 24 Jun 2016 10:04:22 -0700
From: Josh Triplett <josh@...htriplett.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Eric Dumazet <edumazet@...gle.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Chris Mason <clm@...com>,
Arjan van de Ven <arjan@...radead.org>, rt@...utronix.de,
Rik van Riel <riel@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
George Spelvin <linux@...encehorizons.net>,
Len Brown <lenb@...nel.org>
Subject: Re: [patch V3 00/22] timer: Refactor the timer wheel
On Fri, Jun 24, 2016 at 02:32:00PM -0000, Thomas Gleixner wrote:
> - Removed the 1000Hz granularity reduction to 4ms. Eric explained that
> datacenter workloads require the granularity in the first level wheel.
>
> - Fixed the typo in tilepro.
>
> - Converted sigtimedwait() to hrtimers
>
> - To avoid the cascading I extended the wheel by another level. This removes
> the rarely executed cascading code path, but increases the storage size for
> HZ>100 slightly. If the tiny folks care, there is an simple option to cut
> the storage size in half for the price of reduced granularity.
No objection here. This series is a massive improvement for low-power
systems, and the tiniest kernels will probably need to poke at this even
more aggressively anyway. (For instance, compiling out connection
tracking and its incredibly long timer, and then removing the bucket it
needs.)
- Josh Triplett
Powered by blists - more mailing lists