linux-kernel - Re: [patch] timer: Add a mod_timer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.0911231728200.24119@localhost.localdomain>
Date:	Mon, 23 Nov 2009 18:19:20 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Arjan van de Ven <arjan@...radead.org>
cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	alan@...ux.intel.com
Subject: Re: [patch] timer: Add a mod_timer_msec() API function

On Mon, 23 Nov 2009, Arjan van de Ven wrote:
> On Mon, 23 Nov 2009 09:26:48 +0100
> Ingo Molnar <mingo@...e.hu> wrote:
> > 
> > This code first rounds to 1 second - and if that doesnt fall within
> > the slack window it rounds to the (rather aribtrary) rounding of 16
> > jiffies.
> > 
> > I'd suggest to use up the slack to its maximum, by rounding up modulo 
> > the largest power-of-2 value that still fits into the slack.
> > 
> > So if slack is 30, the rounding is 16. If slack is 5, the rounding is
> > 4, etc.
> 
> well.. the point of the rounding is that there is a maximum likelyhood
> that OTHER timers align.
> 
> I suppose what you suggest would do that too; need to think of a clever
> way to not make that expensive
> (after coffee I'll look at if xor + find first bit will work ;-)

I think we need to rethink the timer wheel subsystem in general
instead of adding more and more fancy interfaces.

Looking at the examples you provided for mod_timer_msec() I noticed
that most of the slack values you chose are between 10% and 20% of the
timeout.

That means the larger the timeout the less interesting is the accuracy
which makes a lot of sense.

I really wonder whether there is any timer_list user which has the
need for large and precise timeouts. If not we could simplify the
whole timer wheel business radically and get rid of the worst thing in
it: recascading.

That's what I have in mind:

    	       timeout    accuracy
array0	  <    0.256 s        1 ms
array1	  <    2.560 s       40 ms
array2	  <   25.600 s      400 ms
array3	  <  256.000 s     4000 ms
array4	  >= 256.000 s    40000 ms 

Similar to the current timer wheel, but instead of recascading on
every wraparound of the array0 index we could expire the timers in
array1-4 in their accuracy interval which aligns them automatically
without any slack and rounding business on timer insertion.

The exact array definitions need of course more thought, but you get
the idea.

Such an implementation would also simplify the search for the next
expiring timer as we could keep track of empty/non-empty buckets with
an additional per array bitfield.

If there are a few timers which really need large and precise timeouts
its easy enough to switch them over to hrtimers.

Thoughts ?

Thanks,

	tglx
--
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/