On Thu, 12 Apr 2007 11:36:02 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > OK, so I resurrected x86_64-mm-sched-clock-share.patch and > > x86_64-mm-sched-clock64.patch. The x86_64 box hangs on boot when using > > netconsole and printk timestamps too. Removing "time" from the kernel boot > > command line prevents that. > > Ah. But ktime_get shouldn't printk. Or did you change that? I didn't change anything. If we change printk() to do a read_seqretry(xtime_lock) (as your patches apparently do), then any printk() inside write_seqlock(xtime_lock) will hang. > > > > This explains why the hang only happens with > > x86_64-mm-log-reason-why-tsc-was-marked-unstable.patch applied, too: that > > patch must be triggering a printk inside xtime_lock. > > > > Does someone want to cook up a lockless printk_clock() for i386 and x86_64? > > Just use jiffies directly in printk. That's only HZ accurate, but should > be good enough for printk. Bit sad. printk timestamping was originally implemented as a way of observing and measuring bootup delays. It seems pretty popular now and probably quite a few people like high resolution on it. > One could use pure monotonic xtime as fallback instead of ktime_get in > sched_clock. > The trouble is just that they might cause sched_clock to go backwards during > a temporary instability period (cpufreq change) because the xtime will be > always a bit behind the TSC and a TSC->xtime conversion will lose time. > At least the scheduler doesn't handle backwards time warp on a CPU gratefully. > Ok I guess it could return max(last_value_before_instability, xtime) > I wasn't proposing any change in sched_clock(). I was proposing that i386 and x86_64 be given a new, lockless, high-resolution printk_clock(). Presently x86 uses the default printk_clock(), which uses sched_clock(). Presumably copying the pre-x86_64-mm-sched-clock-share.patch version of sched_clock() into printk_clock() will suffice. - 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/
