Re: sched_clock() uses are broken

Russell King
2006-05-07T13:55:50Z

On Sun, May 07, 2006 at 11:30:15PM +1000, Nick Piggin wrote:
> Russell King wrote:
> >On Sun, May 07, 2006 at 11:00:29PM +1000, Nick Piggin wrote:
> >
> >>Nick Piggin wrote:
> >>
> >>
> >>>I stand by my first reply to your comment WRT the API.
> >>
> >>Actually, on rereading, it seems like I was a bit confused about
> >>your proposal. I don't think you specified anyway the units
> >>returned by your new sched_clock(). So it is identical to my
> >>"corrected" interface :\
> >
> >
> >Okay, so that presumably means we have to either stick with what we
> >currently have, or go the whole hog and re-implement the sched_clock()
> >support?
> >
> >IOW, my patch on 2nd May isn't of any use as it currently stands?
>
> IMO it would probably be best to try to re implement it in one go.
> It shouldn't have spread too far out of kernel/sched.c, and the arch
> code should mostly be implementable in terms of their sched_clock().
> Mundane but not difficult.
>
> Making arch code actually try to do the right thing may require a
> bit more thinking, to handle both the variable time counter issue
> and your time counter wrap problem. That wouldn't be your problem
> though, outside arch/arm/

Also, any comments on update_cpu_clock() and current_sched_time() both
appearing to be buggy, or am I barking up the wrong tree with those?

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core