From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eduardo Habkost Subject: hrtimer_forward() semantics when using non-high-res timers Date: Mon, 24 Nov 2008 15:02:02 -0200 Message-ID: <20081124170202.GD16862@blackpad> References: <20081121170642.GH30825@blackpad> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, Jan Kiszka , Marcelo Tosatti To: linux-kernel@vger.kernel.org, Thomas Gleixner Return-path: Received: from mx2.redhat.com ([66.187.237.31]:51994 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752935AbYKXRCl (ORCPT ); Mon, 24 Nov 2008 12:02:41 -0500 Content-Disposition: inline In-Reply-To: <20081121170642.GH30825@blackpad> Sender: kvm-owner@vger.kernel.org List-ID: 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