linux-kernel - hrtimer_forward() semantics when using non-high-res 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>] [day] [month] [year] [list]

Date:	Mon, 24 Nov 2008 15:02:02 -0200
From:	Eduardo Habkost <ehabkost@...hat.com>
To:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Cc:	kvm@...r.kernel.org, Jan Kiszka <jan.kiszka@....de>,
	Marcelo Tosatti <mtosatti@...hat.com>
Subject: hrtimer_forward() semantics when using non-high-res timers

Hi, Thomas,

I've been looking at a timer problem on KVM recently[1] and I've got a
question about the expected semantics of hrtimer_forward().

The problem I am looking at is related to having proper accouting of
missed ticks on the KVM timer code when it the host has lost timer
ticks because of high CPU load, or because it doesn't have hrtimers
enabled. hrtimer_forward_now() overrun accounting looked perfect for
the task of checking how many ticks we have lost.

However hrtimer_forward() limits the interval parameter to the timer
resolution, making it useless for calculating how many timer periods we've
lost because of too-low timer resolution. I am even a bit surprised no
other code needs a hrtimer_forward-like function for that, yet.

For example: if we want to account for a tick every 1 ms and the host
has HZ=250 and no high-resolution timers, calling hrtimer_forward_now()
on every timer tick will normally return 1 because it will count how
many 4 ms periods were added to the timer expiration time. However,
I would like to calculate how many 1 ms periods I've lost, no matter
what the real timer resolution is.

I could do my own missed-ticks calculation, but the hrtimer_forward()
logic would be perfect for my needs if it didn't have the resolution check
code, and I don't feel like duplicating part of hrtimer_forward(). Do you
think it would make sense to have on the timers API a hrtimer_forward-like
function that doesn't have the interval lower-limit?

[1] http://marc.info/?l=kvm&m=122728725028262&w=2

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