Re: [PATCH] fix for sched_clock() when using jiffies

[Ron]

On Fri, May 08, 2009 at 04:01:42PM -0700, Andrew Morton wrote:
> On Sat, 9 May 2009 05:34:44 +0930
> Ron <ron@xxxxxxxxxx> wrote:
> 
> >  
> > Account for the initial offset to the jiffy count.
> > 
> > Signed-off-by: Ron Lee <ron@xxxxxxxxxx>
> > 
> > ---
> >  kernel/sched_clock.c |    3 ++-
> >  1 files changed, 2 insertions(+), 1 deletions(-)
> > 
> > diff --git a/kernel/sched_clock.c b/kernel/sched_clock.c
> > index a0b0852..a1567b1 100644
> > --- a/kernel/sched_clock.c
> > +++ b/kernel/sched_clock.c
> > @@ -37,7 +37,8 @@
> >   */
> >  unsigned long long __attribute__((weak)) sched_clock(void)
> >  {
> > -	return (unsigned long long)jiffies * (NSEC_PER_SEC / HZ);
> > +	return (unsigned long long)(jiffies - INITIAL_JIFFIES)
> > +					* (NSEC_PER_SEC / HZ);
> >  }
> >  
> >  static __read_mostly int sched_clock_running;
> 
> Why?  I assume that you encountered some problem which was fixed
> by this patch.  What was that problem?

This was a resend of a patch that seemed to get a thumbs up, except
for whitespace damage in what I originally sent, but which apparently
then didn't get applied.  The original context to it was:

 I'm in the process of updating a port for an ARM based chip we've been
 working on, from 2.6.22-rc4'ish to the current HEAD of Linus' tree, and
 I started seeing the following:

 [    0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
 [42949372.970000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)

 The reason appears to be that printk_clock() has been replaced with a
 call to cpu_clock, which in our case currently falls back to the default
 (weak) implementation of sched_clock() that uses jiffies -- but doesn't
 account for the initial offset of the jiffy count.  The following simple
 patch fixes it for me, in line with what printk_clock used to do.

I've since created a 'real' implementation of sched_clock for our port,
so it's no longer an issue for us, but someone else reported this on
#kernelnewbies yesterday, so I figured it was worth forwarding a clean
patch for it once again.

Cheers,
Ron


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/