[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1606151746270.5839@nanos>
Date: Wed, 15 Jun 2016 18:43:46 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Arjan van de Ven <arjanvandeven@...il.com>
cc: Eric Dumazet <edumazet@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Chris Mason <clm@...com>,
Arjan van de Ven <arjan@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [patch 13/20] timer: Switch to a non cascading wheel
On Wed, 15 Jun 2016, Arjan van de Ven wrote:
> what would 1 more timer wheel do?
Waste storage space and make the collection of expired timers more expensive.
The selection of the timer wheel properties is combination of:
1) Granularity
2) Storage space
3) Number of levels to collect
#1 Influences the accuracy of the wheel levels. The worst case error is the
ratio of the shortest timeout in a level and the granularity of that level.
Currently I've chosen 12.5%. If we go to 25% worst case, then we increase
the per level capacity by factor (1 << lvl).
#2 It strikes me a bit silly to waste storage space for esoteric
outliers. According to the data I collected we have no timers at all
between 2hrs and 5 days.
#3 The more levels we have the more steps we have when collecting expired
timers or searching the next expiring timer. It's all bound, but it still
adds up.
Thanks,
tglx
Powered by blists - more mailing lists