* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > the scariest bit is the adding of cpu_clock() to kernel/printk.c so
> > late in the game, and the anti-recursion code i did there. Maybe
> > because this only affects CONFIG_PRINTK_TIME we could try it even
> > for v2.6.24.
>
> Printk recursion I g
On Saturday 08 December 2007 19:52, Ingo Molnar wrote:
> the scariest bit is the adding of cpu_clock() to kernel/printk.c so late
> in the game, and the anti-recursion code i did there. Maybe because this
> only affects CONFIG_PRINTK_TIME we could try it even for v2.6.24.
Printk recursion I guess
On Dec 8, 2007 9:52 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> the scariest bit isnt even the scaling i think - that is a fairly
> straightforward and clean PER_CPU-ization of the global scaling factor,
> and its hookup with cpufreq events. (and the credit for that goes to
> Guillaume Chazarain)
* Michael Buesch <[EMAIL PROTECTED]> wrote:
> > i cannot see how. You can verify msleep by running something like this:
> >
> > while :; do time usleep 111000; done
> >
> > you should see a steady stream of:
> >
> > real0m0.113s
> > real0m0.113s
> > real0m0.113s
> >
> > (on a
On Saturday 08 December 2007 16:33:27 Ingo Molnar wrote:
>
> * Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > On Saturday 08 December 2007 16:13:41 Ingo Molnar wrote:
> > >
> > > * Mark Lord <[EMAIL PROTECTED]> wrote:
> > >
> > > > Ingo Molnar wrote:
> > > >> ...
> > > >> thanks. I do get the
* Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Saturday 08 December 2007 16:13:41 Ingo Molnar wrote:
> >
> > * Mark Lord <[EMAIL PROTECTED]> wrote:
> >
> > > Ingo Molnar wrote:
> > >> ...
> > >> thanks. I do get the impression that most of this can/should wait until
> > >> 2.6.25. The patche
On Saturday 08 December 2007 16:13:41 Ingo Molnar wrote:
>
> * Mark Lord <[EMAIL PROTECTED]> wrote:
>
> > Ingo Molnar wrote:
> >> ...
> >> thanks. I do get the impression that most of this can/should wait until
> >> 2.6.25. The patches look quite dangerous.
> > ..
> >
> > I confess to not really
* Mark Lord <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
>> ...
>> thanks. I do get the impression that most of this can/should wait until
>> 2.6.25. The patches look quite dangerous.
> ..
>
> I confess to not really trying hard to understand everything in this
> thread, but the implication
Ingo Molnar wrote:
...
thanks. I do get the impression that most of this can/should wait until
2.6.25. The patches look quite dangerous.
..
I confess to not really trying hard to understand everything in this thread,
but the implication seems to be that this bug might affect udelay()
and possi
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> On Saturday 08 December 2007 11:50, Nick Piggin wrote:
>
> > I guess your patch is fairly complex but it should work
>
> I should also add that although complex, it should have a much smaller
> TSC delta window in which the wrong scaling factor can ge
On Saturday 08 December 2007 11:50, Nick Piggin wrote:
> I guess your patch is fairly complex but it should work
I should also add that although complex, it should have a
much smaller TSC delta window in which the wrong scaling
factor can get applied to it (I guess it is about as good
as you can
On Saturday 08 December 2007 03:48, Nick Piggin wrote:
> On Friday 07 December 2007 22:17, Ingo Molnar wrote:
> > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > > ah, printk_clock() still uses sched_clock(), not jiffies. So it's
> > > > not the jiffies counter that goes back and forth, it's sched_c
* Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> Le Fri, 7 Dec 2007 15:54:18 +0100,
> Ingo Molnar <[EMAIL PROTECTED]> a écrit :
>
> > This is a version that
> > is supposed fix all known aspects of TSC and frequency-change
> > weirdnesses.
>
> Tested it with frequency changes, the clock is
Le Fri, 7 Dec 2007 15:54:18 +0100,
Ingo Molnar <[EMAIL PROTECTED]> a écrit :
> This is a version that
> is supposed fix all known aspects of TSC and frequency-change
> weirdnesses.
Tested it with frequency changes, the clock is as smooth as I like
it :-)
The only remaining sched_clock user in
On Friday 07 December 2007 22:17, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > ah, printk_clock() still uses sched_clock(), not jiffies. So it's
> > > not the jiffies counter that goes back and forth, it's sched_clock()
> > > - so this is a printk timestamps anomaly, not rela
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> third update. the cpufreq callbacks are not quite OK yet.
fourth update - the cpufreq callbacks are back. This is a version that
is supposed fix all known aspects of TSC and frequency-change
weirdnesses.
Ingo
Index: linux/arch/arm/kernel/tim
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Stefano, could you try this ontop of a recent-ish Linus tree - does
> > this resolve all issues? (without introducing new ones ;-)
>
> updated version attached below.
third update. the cpufreq callbacks are not quite OK yet.
Ingo
Index: li
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> ok, here's a rollup of 11 patches that relate to this. I hoped we
> could wait with this for 2.6.25, but it seems more urgent as per
> Stefano's testing, as udelay() and drivers are affected as well.
>
> Stefano, could you try this ontop of a recent-i
ok, here's a rollup of 11 patches that relate to this. I hoped we could
wait with this for 2.6.25, but it seems more urgent as per Stefano's
testing, as udelay() and drivers are affected as well.
Stefano, could you try this ontop of a recent-ish Linus tree - does this
resolve all issues? (with
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> It's a single CPU box, so sched_clock() jumping would still be
>> problematic, no?
>
> I guess so. Definitely, it didn't look like a printk issue. Drivers
> don't read logs, usually. But they got confused anyway (it seems that
> udelay's get sc
On Dec 7, 2007 12:18 PM, Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> Any pointer to it?
Nevermind, I found it ... in this same thread :-(
--
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> My patch should fix the worst cpufreq sched_clock jumping issue I
> think.
but it degrades the precision of sched_clock() and has other problems as
well. cpu_clock() is the right interface to use for such things.
Ingo
--
To unsubscribe from t
Quoting Nick Piggin <[EMAIL PROTECTED]>:
On Friday 07 December 2007 19:45, Ingo Molnar wrote:
ah, printk_clock() still uses sched_clock(), not jiffies. So it's not
the jiffies counter that goes back and forth, it's sched_clock() - so
this is a printk timestamps anomaly, not related to jiffies.
On Dec 7, 2007 12:13 PM, Nick Piggin <[EMAIL PROTECTED]> wrote:
> My patch should fix the worst cpufreq sched_clock jumping issue
> I think.
Any pointer to it?
Thanks.
--
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROT
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > ah, printk_clock() still uses sched_clock(), not jiffies. So it's
> > not the jiffies counter that goes back and forth, it's sched_clock()
> > - so this is a printk timestamps anomaly, not related to jiffies. I
> > thought we have fixed this bug in
On Friday 07 December 2007 19:45, Ingo Molnar wrote:
> * Stefano Brivio <[EMAIL PROTECTED]> wrote:
> > This patch fixes a regression introduced by:
> >
> > commit bb29ab26863c022743143f27956cc0ca362f258c
> > Author: Ingo Molnar <[EMAIL PROTECTED]>
> > Date: Mon Jul 9 18:51:59 2007 +0200
> >
> > T
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > A bit risky - it's quite an expansion of code which no longer can
> > > call printk.
> > >
> > > You might want to take that WARN_ON out of __update_rq_clock() ;)
> >
> > hm, dont we already detect printk recursions and turn them into a
> > sil
On Fri, 7 Dec 2007 11:40:13 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > - t = printk_clock();
> > > + t = cpu_clock(printk_cpu);
> > > nanosec_rem = do_div(t, 100
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > > - t = printk_clock();
> > > + t = cpu_clock(printk_cpu);
> > > nanosec_rem = do_div(t, 10);
> > > tlen = sprintf(tbuf,
> > >
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> > - t = printk_clock();
> > + t = cpu_clock(printk_cpu);
> > nanosec_rem = do_div(t, 10);
> > tlen = sprintf(tbuf,
> >
Thomas Gleixner <[EMAIL PROTECTED]> writes:
>
> Hmrpf. sched_clock() is used for the time stamp of the printks. We
> need to find some better solution other than killing off the tsc
> access completely.
Doing it properly requires pretty much most of my old sched-clock ff patch.
Complicated and not
On Fri, 7 Dec 2007 09:45:59 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Stefano Brivio <[EMAIL PROTECTED]> wrote:
>
> > This patch fixes a regression introduced by:
> >
> > commit bb29ab26863c022743143f27956cc0ca362f258c
> > Author: Ingo Molnar <[EMAIL PROTECTED]>
> > Date: Mon Jul 9 1
* Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> I'll clean it up and resend it later. As I don't have the necessary
> knowledge to do the tsc_{32,64}.c unification, should I copy paste
> common functions into tsc_32.c and tsc_64.c to ease later unification
> or should I start a common .c fi
Le Fri, 7 Dec 2007 09:51:21 +0100,
Ingo Molnar <[EMAIL PROTECTED]> a écrit :
> yeah, we can do something like this in 2.6.25 - this will improve the
> quality of sched_clock().
Thanks a lot for your interest!
I'll clean it up and resend it later. As I don't have the necessary
knowledge to do th
* Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> > Something like http://lkml.org/lkml/2007/3/16/291 that would need
> > some refresh?
>
> And here is a refreshed one just for testing with 2.6-git. The 64 bit
> part is a shamelessly untested copy/paste as I cannot test it.
yeah, we can do s
* Stefano Brivio <[EMAIL PROTECTED]> wrote:
> This patch fixes a regression introduced by:
>
> commit bb29ab26863c022743143f27956cc0ca362f258c
> Author: Ingo Molnar <[EMAIL PROTECTED]>
> Date: Mon Jul 9 18:51:59 2007 +0200
>
> This caused the jiffies counter to leap back and forth on cpufreq
"Guillaume Chazarain" <[EMAIL PROTECTED]> wrote:
> On Dec 7, 2007 6:51 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> > Hmrpf. sched_clock() is used for the time stamp of the printks. We
> > need to find some better solution other than killing off the tsc
> > access completely.
>
> Something li
On Dec 7, 2007 6:51 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> Hmrpf. sched_clock() is used for the time stamp of the printks. We
> need to find some better solution other than killing off the tsc
> access completely.
Something like http://lkml.org/lkml/2007/3/16/291 that would need some ref
On Fri, 7 Dec 2007, Stefano Brivio wrote:
> This patch fixes a regression introduced by:
>
> commit bb29ab26863c022743143f27956cc0ca362f258c
> Author: Ingo Molnar <[EMAIL PROTECTED]>
> Date: Mon Jul 9 18:51:59 2007 +0200
>
> This caused the jiffies counter to leap back and forth on cpufreq cha
On Friday 07 December 2007 12:19, Stefano Brivio wrote:
> This patch fixes a regression introduced by:
>
> commit bb29ab26863c022743143f27956cc0ca362f258c
> Author: Ingo Molnar <[EMAIL PROTECTED]>
> Date: Mon Jul 9 18:51:59 2007 +0200
>
> This caused the jiffies counter to leap back and forth on
This patch fixes a regression introduced by:
commit bb29ab26863c022743143f27956cc0ca362f258c
Author: Ingo Molnar <[EMAIL PROTECTED]>
Date: Mon Jul 9 18:51:59 2007 +0200
This caused the jiffies counter to leap back and forth on cpufreq changes
on my x86 box. I'd say that we can't always assume t
41 matches
Mail list logo
