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

Paul Mundt
2009-05-09T12:47:41Z

On Fri, May 08, 2009 at 06:15:59PM -0700, Andrew Morton wrote:
> On Sat, 9 May 2009 10:10:09 +0930 Ron <ron@debian.org> wrote:
> > 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.
>
> Removing printk_clock() always seemed a mildly wrong idea to me.
>
> I'm sure we fixed this printk-timestamping ages and ages ago. Maybe it
> came back, or maybe it's somehow specific to your setup?
>
FWIW, I just ran in to this yesterday on a board with a single timer
channel (which is assigned over to clockevents so we can still do
tickless), using the jiffies clocksource. With printk_clock() gone, it
seems like anything using the jiffies clocksource ought to have this
problem.