On Wed, 2007-05-16 at 09:42 +0200, Francis Moreau wrote:
> > On Tue, 2007-05-15 at 10:47 +0200, Francis Moreau wrote:
> > > My question is about the clock resolution field which is equal to 1ns.
> > > How is this possible since my timer's frequency is only 100Mhz ?
> >
> > you are right. It is a bit strange. The resolution info is not really
> > reflecting the clock event source capability. I look if there is a sane
> > solution for that.
> >
>
> Doesn't that make hrtimer_get_res() and its callers buggy since they
> return this 1ns value which is not reflecting the correct clock event
> capability ?
Well, it's not really buggy. It's just not telling the truth.
> Another question about the output of '/proc/timer_list':
>
> [...]
> active timers:
> #0: <c03fde10>, tick_sched_timer, S:01
> # expires at 64696546875000 nsecs [in 2514469 nsecs]
> .expires_next : 64696546875000 nsecs
> [...]
>
> Doesn't the 2 expire time lines give the same information ? If so,
> couldn't we merge them into : ".expires_next : 64696546875000 nsecs
> [in 2514469 nsecs]" ?
No. The timers are taken from the hrtimer queue and the expires_next
value is the clock events code internal value of the next timer event.
The expiry time of the first timer and the clock events code should
match of course, but we definitely want to have them seperate.
tglx
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
