linux-kernel - RE: [RFC] Imprecise timers.

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]

Date:	Mon, 28 Jul 2008 17:36:57 -0700
From:	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
To:	David Woodhouse <dwmw2@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
	"arjan@...radead.org" <arjan@...radead.org>
Subject: RE: [RFC] Imprecise timers.

>-----Original Message-----
>From: linux-kernel-owner@...r.kernel.org
>[mailto:linux-kernel-owner@...r.kernel.org] On Behalf Of David
>Woodhouse
>Sent: Monday, July 21, 2008 8:03 PM
>To: linux-kernel@...r.kernel.org
>Cc: Thomas Gleixner; Ingo Molnar; arjan@...radead.org
>Subject: [RFC] Imprecise timers.
>
>Many users of timers don't really care too much about exactly
>when their
>timer fires -- and waking a CPU to satisfy such a timer is a waste of
>power. This patch implements a 'range' timer which will fire
>at a 'convenient'
>moment within given constraints.
>
>It's implemented by a deferrable timer at the beginning of the range,
>which will run some time later when the CPU happens to be awake. And a
>non-deferrable timer at the hard deadline, to ensure it really does
>happen by then.
>

One concern I have is drivers using range_timers thinking that they need
some upper bound, while all they need is a simple deferrable timer. With that
we will have multiple timers waking up the CPU all the time (say, on
different CPUs) problem again. Even without the timers waking up all
the time problem, we have extra overhead of one or more spinlocks
just to delete one extra unused timer. I don't how, but
we will have to restrict this somehow to only code that really needs this
kind of deadline.

Regarding implementation, I am thinking mod_range_timer should use
ret &= mod_timer(). That is, if one of the timers has already fired and
the other one is pending mod_range_timer return value should say it has
already fired. Right?

Also, do we need both mod_range_timer and __mod_range_timer.
Original mod_timer version talks about optimization for networking code.
I think we can do with only one of the two here...

Thanks,
Venki

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