On 03/06/2007 05:18 PM, Thomas Gleixner wrote:
On Tue, 2007-03-06 at 16:53 -0800, Dan Hecht wrote:
Ooops. I completely forgot, that you get the absolute expiry time
already in ktime_t format (nanoseconds) when dev->set_next_event() is
called.
dev->next_event = expires;
is done right before the call.
So it's already there for free.
Okay. I noticed that but didn't think it was okay to use since it
didn't seem like it was set up for the clock_event_device code's use, so
seemed like a conceptual interface violation to go digging around in
there.
Yes it is.
I just wanted to point out that you can use it until I'm awake enough to
implement it proper.
Well, we'll probably just live with using the relative expiry for the
first pass, and then revisit this later once that is working, rather
than resort to hacking it out by reading ->next_event.
Also, wasn't one of the points of clockevents to prevent the device code
from doing conversions between nanoseconds and clicks themselves? Don't
we really want the clockevents generic layer to do this conversion
between monotonic nanonseconds to absolute device clicks and then give
the device code that value, so the device layer doesn't perform any
conversions?
Right. But this applies only to deltas, as the conversion of absolute
time values gets ugly, i.e. 128bit math
Yeah, hopefully we can come up with a clean way to do this. But, like I
said early, until we do, we'll stick with the relative expiry.
IMO the paravirt interfaces should use nanoseconds anyway for both
readout and next event programming. That way the conversion is done in
the hypervisor once and the clocksources and clockevents are simple and
unified (except for the underlying hypervisor calls).
I disagree. The clocksource/clockevents layer are always going to have
to convert nanoseconds to/from hardware units, so why not use it? And,
some guests (say, a future version of linux that does trace-based
process accounting) may want higher resolution than nanoseconds for
certain uses. In any case, this is beside the point; I'd prefer to
stick to using the clockevents interface in the way it was intended
rather than reaching into ->next_event.
thanks,
Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
