Re: mm snapshot broken-out-2007-04-25-02-49.tar.gz uploaded

From: Andi Kleen
Date: Wed Apr 25 2007 - 16:48:27 EST

On Wednesday 25 April 2007 22:42:44 Jeremy Fitzhardinge wrote:
> Michal Piotrowski wrote:
> > Timing information is broken
> >
> This looks like Andi's sched_clock stuff hitting: it returns an
> inherently per-cpu result, so using it for printk timestamps isn't very
> useful.

It should actually roughly work. There can be some drift, but there shouldn't
be that much error. All CPUs should tick at roughly the same rate because
it's scaled to nanoseconds

If the drift is a big issue it would also be possible to resync every minute
or so, but I haven't implemented that.

There will be always some minor monotonicities because it won't try
to stop the CPU from reordering instructions.

I don't know why it is that off in your case.

> > [4294667.511000] BUG: at arch/i386/kernel/sched-clock.c:175 init_sched_clock()
> > [4294667.511000] [<c01052e0>] dump_trace+0x63/0x1eb
> > [4294667.511000] [<c0105482>] show_trace_log_lvl+0x1a/0x30
> > [4294667.511000] [<c01060c4>] show_trace+0x12/0x14
> > [4294667.511000] [<c0106161>] dump_stack+0x16/0x18
> > [4294667.511000] [<c04fd968>] init_sched_clock+0x6d/0xcc
> > [4294667.512000] [<c04f8505>] kernel_init+0x14e/0x2bf
> > [4294667.512000] [<c0104ec3>] kernel_thread_helper+0x7/0x10
> > [4294667.512000] =======================
> This also seems to be the sched_clock change; the WARN_ON is asserting
> that it got initialized early enough, but it isn't.

That's already fixed.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at