* CONFIG_PRINTK_TIME broken on git HEAD ?
@ 2008-05-07 22:26 Gabriel C
2008-05-07 22:41 ` Andrew Morton
0 siblings, 1 reply; 10+ messages in thread
From: Gabriel C @ 2008-05-07 22:26 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Andrew Morton
Hi all,
I've updated today to 2.6.26-rc1-00166-gc0a1811 , running an 64bit kernel at the moment.
dmesg shows here :
...
[ 0.000000] Allocating PCI resources starting at d0000000 (gap: cf600000:2f800000)
[ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[ 0.000000] PERCPU: Allocating 42756 bytes of per cpu data
[ 0.000000] NR_CPUS: 8, nr_cpu_ids: 4
[4294014.506571] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1010753
[4294014.506571] Kernel command line: root=/dev/sdb1 ro debug vga=0x317
[4294014.506571] Initializing CPU#0
[4294014.506571] Preemptible RCU implementation.
[4294014.506571] PID hash table entries: 4096 (order: 12, 32768 bytes)
...
Is this a known issue ?
Regards,
Gabriel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: CONFIG_PRINTK_TIME broken on git HEAD ?
2008-05-07 22:26 CONFIG_PRINTK_TIME broken on git HEAD ? Gabriel C
@ 2008-05-07 22:41 ` Andrew Morton
2008-05-07 22:57 ` Gabriel C
0 siblings, 1 reply; 10+ messages in thread
From: Andrew Morton @ 2008-05-07 22:41 UTC (permalink / raw)
To: Gabriel C; +Cc: linux-kernel, Rafael J. Wysocki
On Thu, 08 May 2008 00:26:04 +0200
Gabriel C <nix.or.die@googlemail.com> wrote:
> Hi all,
>
> I've updated today to 2.6.26-rc1-00166-gc0a1811 , running an 64bit kernel at the moment.
Which kernel were you runing previously?
> dmesg shows here :
>
> ...
>
>
> [ 0.000000] Allocating PCI resources starting at d0000000 (gap: cf600000:2f800000)
> [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
> [ 0.000000] PERCPU: Allocating 42756 bytes of per cpu data
> [ 0.000000] NR_CPUS: 8, nr_cpu_ids: 4
> [4294014.506571] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1010753
> [4294014.506571] Kernel command line: root=/dev/sdb1 ro debug vga=0x317
> [4294014.506571] Initializing CPU#0
> [4294014.506571] Preemptible RCU implementation.
> [4294014.506571] PID hash table entries: 4096 (order: 12, 32768 bytes)
>
> ...
>
>
> Is this a known issue ?
>
Not to me.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: CONFIG_PRINTK_TIME broken on git HEAD ?
2008-05-07 22:41 ` Andrew Morton
@ 2008-05-07 22:57 ` Gabriel C
2008-05-08 11:00 ` Gabriel C
0 siblings, 1 reply; 10+ messages in thread
From: Gabriel C @ 2008-05-07 22:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Rafael J. Wysocki
Andrew Morton wrote:
> On Thu, 08 May 2008 00:26:04 +0200
> Gabriel C <nix.or.die@googlemail.com> wrote:
>
>> Hi all,
>>
>> I've updated today to 2.6.26-rc1-00166-gc0a1811 , running an 64bit kernel at the moment.
>
> Which kernel were you runing previously?
2.6.25* , tested 2.6.25-git* , 2.6.26-rc1 , and 2.6.26-rc1-00065-g5717922.
>From my log 2.6.26-rc1-00065-g5717922 was fine.
...
May 6 00:13:14 thor kernel: [ 0.000000] Allocating PCI resources starting at d0000000 (gap: cf600000:2f800000)
May 6 00:13:14 thor kernel: [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
May 6 00:13:14 thor kernel: [ 0.000000] PERCPU: Allocating 41732 bytes of per cpu data
May 6 00:13:14 thor kernel: [ 0.000000] Kernel command line: root=/dev/sdb1 ro debug vga=0x317
May 6 00:13:14 thor kernel: [ 0.000000] Preemptible RCU implementation.
May 6 00:13:14 thor kernel: [ 0.000000] Extended CMOS year: 2000
May 6 00:13:14 thor kernel: [ 0.000000] TSC calibrated against PM_TIMER
May 6 00:13:14 thor kernel: [ 0.000014] time.c: Detected 2499.952 MHz processor.
May 6 00:13:14 thor kernel: [ 0.000032] console [tty0] enabled
May 6 00:13:14 thor kernel: [ 0.000999] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
May 6 00:13:14 thor kernel: [ 0.000999] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
May 6 00:13:14 thor kernel: [ 0.000999] Checking aperture...
...
>
>> dmesg shows here :
>>
>> ...
>>
>>
>> [ 0.000000] Allocating PCI resources starting at d0000000 (gap: cf600000:2f800000)
>> [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
>> [ 0.000000] PERCPU: Allocating 42756 bytes of per cpu data
>> [ 0.000000] NR_CPUS: 8, nr_cpu_ids: 4
>> [4294014.506571] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1010753
>> [4294014.506571] Kernel command line: root=/dev/sdb1 ro debug vga=0x317
>> [4294014.506571] Initializing CPU#0
>> [4294014.506571] Preemptible RCU implementation.
>> [4294014.506571] PID hash table entries: 4096 (order: 12, 32768 bytes)
>>
>> ...
>>
>>
>> Is this a known issue ?
>>
>
> Not to me.
>
Gabriel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: CONFIG_PRINTK_TIME broken on git HEAD ?
2008-05-07 22:57 ` Gabriel C
@ 2008-05-08 11:00 ` Gabriel C
2008-05-08 11:13 ` Peter Zijlstra
0 siblings, 1 reply; 10+ messages in thread
From: Gabriel C @ 2008-05-08 11:00 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, Rafael J. Wysocki, Peter Zijlstra, Ingo Molnar
Gabriel C wrote:
> Andrew Morton wrote:
>> On Thu, 08 May 2008 00:26:04 +0200
>> Gabriel C <nix.or.die@googlemail.com> wrote:
>>
>>> Hi all,
>>>
>>> I've updated today to 2.6.26-rc1-00166-gc0a1811 , running an 64bit kernel at the moment.
>> Which kernel were you runing previously?
>
> 2.6.25* , tested 2.6.25-git* , 2.6.26-rc1 , and 2.6.26-rc1-00065-g5717922.
>
>
>>From my log 2.6.26-rc1-00065-g5717922 was fine.
>
> ...
>
> May 6 00:13:14 thor kernel: [ 0.000000] Allocating PCI resources starting at d0000000 (gap: cf600000:2f800000)
> May 6 00:13:14 thor kernel: [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
> May 6 00:13:14 thor kernel: [ 0.000000] PERCPU: Allocating 41732 bytes of per cpu data
> May 6 00:13:14 thor kernel: [ 0.000000] Kernel command line: root=/dev/sdb1 ro debug vga=0x317
> May 6 00:13:14 thor kernel: [ 0.000000] Preemptible RCU implementation.
> May 6 00:13:14 thor kernel: [ 0.000000] Extended CMOS year: 2000
> May 6 00:13:14 thor kernel: [ 0.000000] TSC calibrated against PM_TIMER
> May 6 00:13:14 thor kernel: [ 0.000014] time.c: Detected 2499.952 MHz processor.
> May 6 00:13:14 thor kernel: [ 0.000032] console [tty0] enabled
> May 6 00:13:14 thor kernel: [ 0.000999] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
> May 6 00:13:14 thor kernel: [ 0.000999] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
> May 6 00:13:14 thor kernel: [ 0.000999] Checking aperture...
>
> ...
>
>>> dmesg shows here :
>>>
>>> ...
>>>
>>>
>>> [ 0.000000] Allocating PCI resources starting at d0000000 (gap: cf600000:2f800000)
>>> [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
>>> [ 0.000000] PERCPU: Allocating 42756 bytes of per cpu data
>>> [ 0.000000] NR_CPUS: 8, nr_cpu_ids: 4
>>> [4294014.506571] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1010753
>>> [4294014.506571] Kernel command line: root=/dev/sdb1 ro debug vga=0x317
>>> [4294014.506571] Initializing CPU#0
>>> [4294014.506571] Preemptible RCU implementation.
>>> [4294014.506571] PID hash table entries: 4096 (order: 12, 32768 bytes)
>>>
>>> ...
>>>
>>>
>>> Is this a known issue ?
>>>
>> Not to me.
>>
>
I've bisected it.
git bisect log
git-bisect start
# good: [2ddcca36c8bcfa251724fe342c8327451988be0d] Linux 2.6.26-rc1
git-bisect good 2ddcca36c8bcfa251724fe342c8327451988be0d
# bad: [3de2403e6659d71b36ec820dc9b942762ddfe6eb] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6
git-bisect bad 3de2403e6659d71b36ec820dc9b942762ddfe6eb
# bad: [aac6abca858386438d9a7233c3471d2ecfa2f704] sched: default to n for GROUP_SCHED and FAIR_GROUP_SCHED
git-bisect bad aac6abca858386438d9a7233c3471d2ecfa2f704
# good: [45ea2103d8856454503b30464cc1dba378748d00] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86-fixes
git-bisect good 45ea2103d8856454503b30464cc1dba378748d00
# good: [5717922a1b8cc477f45a0f4f11fe619392ba7133] Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb
git-bisect good 5717922a1b8cc477f45a0f4f11fe619392ba7133
# good: [b328ca182f01c2a04b85e0ee8a410720b104fbcc] sched: fix hrtick_start_fair and CPU-Hotplug
git-bisect good b328ca182f01c2a04b85e0ee8a410720b104fbcc
# good: [712555ee4f873515612f89554ad1a3fda5fa887e] sched: fix missing locking in sched_domains code
git-bisect good 712555ee4f873515612f89554ad1a3fda5fa887e
# good: [dfbf4a1bc319f0f9a31e39b2da1fa5c55e85af89] sched: fix cpu clock
git-bisect good dfbf4a1bc319f0f9a31e39b2da1fa5c55e85af89
# bad: [3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd] sched: add optional support for CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
git-bisect bad 3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd
# good: [a5574cf65b5f03ce9ade3918764fe22e5e2371e3] sched, x86: add HAVE_UNSTABLE_SCHED_CLOCK
git-bisect good a5574cf65b5f03ce9ade3918764fe22e5e2371e3
cat ./.git/refs/bisect/bad
3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd
git show 3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd
commit 3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Sat May 3 18:29:28 2008 +0200
sched: add optional support for CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
this replaces the rq->clock stuff (and possibly cpu_clock()).
- architectures that have an 'imperfect' hardware clock can set
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
- the 'jiffie' window might be superfulous when we update tick_gtod
before the __update_sched_clock() call in sched_clock_tick()
- cpu_clock() might be implemented as:
sched_clock_cpu(smp_processor_id())
if the accuracy proves good enough - how far can TSC drift in a
single jiffie when considering the filtering and idle hooks?
[ mingo@elte.hu: various fixes and cleanups ]
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Gabriel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: CONFIG_PRINTK_TIME broken on git HEAD ?
2008-05-08 11:00 ` Gabriel C
@ 2008-05-08 11:13 ` Peter Zijlstra
2008-05-08 11:21 ` Gabriel C
0 siblings, 1 reply; 10+ messages in thread
From: Peter Zijlstra @ 2008-05-08 11:13 UTC (permalink / raw)
To: Gabriel C
Cc: Andrew Morton, linux-kernel, Rafael J. Wysocki, Ingo Molnar,
Thomas Gleixner
On Thu, 2008-05-08 at 13:00 +0200, Gabriel C wrote:
> >>From my log 2.6.26-rc1-00065-g5717922 was fine.
> >
>
> > May 6 00:13:14 thor kernel: [ 0.000000] Allocating PCI resources starting at d0000000 (gap: cf600000:2f800000)
> > May 6 00:13:14 thor kernel: [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
> > May 6 00:13:14 thor kernel: [ 0.000000] PERCPU: Allocating 41732 bytes of per cpu data
> > May 6 00:13:14 thor kernel: [ 0.000000] Kernel command line: root=/dev/sdb1 ro debug vga=0x317
> > May 6 00:13:14 thor kernel: [ 0.000000] Preemptible RCU implementation.
> > May 6 00:13:14 thor kernel: [ 0.000000] Extended CMOS year: 2000
> > May 6 00:13:14 thor kernel: [ 0.000000] TSC calibrated against PM_TIMER
> > May 6 00:13:14 thor kernel: [ 0.000014] time.c: Detected 2499.952 MHz processor.
> > May 6 00:13:14 thor kernel: [ 0.000032] console [tty0] enabled
> > May 6 00:13:14 thor kernel: [ 0.000999] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
> > May 6 00:13:14 thor kernel: [ 0.000999] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
> > May 6 00:13:14 thor kernel: [ 0.000999] Checking aperture...
> >
> > ...
> >
> >>> dmesg shows here :
> >>>
> >>> ...
> >>>
> >>>
> >>> [ 0.000000] Allocating PCI resources starting at d0000000 (gap: cf600000:2f800000)
> >>> [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
> >>> [ 0.000000] PERCPU: Allocating 42756 bytes of per cpu data
> >>> [ 0.000000] NR_CPUS: 8, nr_cpu_ids: 4
> >>> [4294014.506571] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1010753
> >>> [4294014.506571] Kernel command line: root=/dev/sdb1 ro debug vga=0x317
> >>> [4294014.506571] Initializing CPU#0
> >>> [4294014.506571] Preemptible RCU implementation.
> >>> [4294014.506571] PID hash table entries: 4096 (order: 12, 32768 bytes)
> I've bisected it.
> cat ./.git/refs/bisect/bad
> 3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd
>
> git show 3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd
> commit 3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd
> Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date: Sat May 3 18:29:28 2008 +0200
>
> sched: add optional support for CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
>
> this replaces the rq->clock stuff (and possibly cpu_clock()).
>
> - architectures that have an 'imperfect' hardware clock can set
> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
>
> - the 'jiffie' window might be superfulous when we update tick_gtod
> before the __update_sched_clock() call in sched_clock_tick()
>
> - cpu_clock() might be implemented as:
>
> sched_clock_cpu(smp_processor_id())
>
> if the accuracy proves good enough - how far can TSC drift in a
> single jiffie when considering the filtering and idle hooks?
>
> [ mingo@elte.hu: various fixes and cleanups ]
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>
Ok, so the issue is that the clock doesn't start at 0, but at:
4294014.506571 ?
I guess that's a side-effect of using ktime to base the clock off.
Thomas, do we have a clock that is uptime based?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: CONFIG_PRINTK_TIME broken on git HEAD ?
2008-05-08 11:13 ` Peter Zijlstra
@ 2008-05-08 11:21 ` Gabriel C
2008-05-09 9:39 ` Peter Zijlstra
0 siblings, 1 reply; 10+ messages in thread
From: Gabriel C @ 2008-05-08 11:21 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Andrew Morton, linux-kernel, Rafael J. Wysocki, Ingo Molnar,
Thomas Gleixner
Peter Zijlstra wrote:
> On Thu, 2008-05-08 at 13:00 +0200, Gabriel C wrote:
>
>>> >From my log 2.6.26-rc1-00065-g5717922 was fine.
>>>
>>
>>> May 6 00:13:14 thor kernel: [ 0.000000] Allocating PCI resources starting at d0000000 (gap: cf600000:2f800000)
>>> May 6 00:13:14 thor kernel: [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
>>> May 6 00:13:14 thor kernel: [ 0.000000] PERCPU: Allocating 41732 bytes of per cpu data
>>> May 6 00:13:14 thor kernel: [ 0.000000] Kernel command line: root=/dev/sdb1 ro debug vga=0x317
>>> May 6 00:13:14 thor kernel: [ 0.000000] Preemptible RCU implementation.
>>> May 6 00:13:14 thor kernel: [ 0.000000] Extended CMOS year: 2000
>>> May 6 00:13:14 thor kernel: [ 0.000000] TSC calibrated against PM_TIMER
>>> May 6 00:13:14 thor kernel: [ 0.000014] time.c: Detected 2499.952 MHz processor.
>>> May 6 00:13:14 thor kernel: [ 0.000032] console [tty0] enabled
>>> May 6 00:13:14 thor kernel: [ 0.000999] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
>>> May 6 00:13:14 thor kernel: [ 0.000999] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
>>> May 6 00:13:14 thor kernel: [ 0.000999] Checking aperture...
>>>
>>> ...
>>>
>>>>> dmesg shows here :
>>>>>
>>>>> ...
>>>>>
>>>>>
>>>>> [ 0.000000] Allocating PCI resources starting at d0000000 (gap: cf600000:2f800000)
>>>>> [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
>>>>> [ 0.000000] PERCPU: Allocating 42756 bytes of per cpu data
>>>>> [ 0.000000] NR_CPUS: 8, nr_cpu_ids: 4
>>>>> [4294014.506571] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1010753
>>>>> [4294014.506571] Kernel command line: root=/dev/sdb1 ro debug vga=0x317
>>>>> [4294014.506571] Initializing CPU#0
>>>>> [4294014.506571] Preemptible RCU implementation.
>>>>> [4294014.506571] PID hash table entries: 4096 (order: 12, 32768 bytes)
>
>
>> I've bisected it.
>
>> cat ./.git/refs/bisect/bad
>> 3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd
>>
>> git show 3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd
>> commit 3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd
>> Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
>> Date: Sat May 3 18:29:28 2008 +0200
>>
>> sched: add optional support for CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
>>
>> this replaces the rq->clock stuff (and possibly cpu_clock()).
>>
>> - architectures that have an 'imperfect' hardware clock can set
>> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
>>
>> - the 'jiffie' window might be superfulous when we update tick_gtod
>> before the __update_sched_clock() call in sched_clock_tick()
>>
>> - cpu_clock() might be implemented as:
>>
>> sched_clock_cpu(smp_processor_id())
>>
>> if the accuracy proves good enough - how far can TSC drift in a
>> single jiffie when considering the filtering and idle hooks?
>>
>> [ mingo@elte.hu: various fixes and cleanups ]
>>
>> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
>> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>>
>
> Ok, so the issue is that the clock doesn't start at 0, but at:
> 4294014.506571 ?
At least on my box , yes.
There is a similar report http://lkml.org/lkml/2008/5/8/100 , there it jumps to 42949372.961619
> I guess that's a side-effect of using ktime to base the clock off.
> Thomas, do we have a clock that is uptime based?
>
Gabriel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: CONFIG_PRINTK_TIME broken on git HEAD ?
2008-05-08 11:21 ` Gabriel C
@ 2008-05-09 9:39 ` Peter Zijlstra
2008-05-09 9:42 ` Ingo Molnar
2008-05-09 12:13 ` Gabriel C
0 siblings, 2 replies; 10+ messages in thread
From: Peter Zijlstra @ 2008-05-09 9:39 UTC (permalink / raw)
To: Gabriel C
Cc: Andrew Morton, linux-kernel, Rafael J. Wysocki, Ingo Molnar,
Thomas Gleixner
On Thu, 2008-05-08 at 13:21 +0200, Gabriel C wrote:
> > Ok, so the issue is that the clock doesn't start at 0, but at:
> > 4294014.506571 ?
>
> At least on my box , yes.
>
Does this work for you?
---
Subject: sched: fixup sched-clock offset
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
It could happen that ktime doesn't start at 0.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
kernel/sched_clock.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
Index: linux-2.6-2/kernel/sched_clock.c
===================================================================
--- linux-2.6-2.orig/kernel/sched_clock.c
+++ linux-2.6-2/kernel/sched_clock.c
@@ -59,21 +59,23 @@ static inline struct sched_clock_data *c
return &per_cpu(sched_clock_data, cpu);
}
+static __read_mostly u64 ktime_offset;
+
void sched_clock_init(void)
{
- u64 ktime_now = ktime_to_ns(ktime_get());
- u64 now = 0;
int cpu;
+ ktime_offset = ktime_to_ns(ktime_get());
+
for_each_possible_cpu(cpu) {
struct sched_clock_data *scd = cpu_sdc(cpu);
scd->lock = (raw_spinlock_t)__RAW_SPIN_LOCK_UNLOCKED;
scd->prev_jiffies = jiffies;
- scd->prev_raw = now;
- scd->tick_raw = now;
- scd->tick_gtod = ktime_now;
- scd->clock = ktime_now;
+ scd->prev_raw = 0;
+ scd->tick_raw = 0;
+ scd->tick_gtod = 0;
+ scd->clock = 0;
}
}
@@ -177,7 +179,7 @@ void sched_clock_tick(void)
WARN_ON_ONCE(!irqs_disabled());
now = sched_clock();
- now_gtod = ktime_to_ns(ktime_get());
+ now_gtod = ktime_to_ns(ktime_get()) - ktime_offset;
__raw_spin_lock(&scd->lock);
__update_sched_clock(scd, now);
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: CONFIG_PRINTK_TIME broken on git HEAD ?
2008-05-09 9:39 ` Peter Zijlstra
@ 2008-05-09 9:42 ` Ingo Molnar
2008-05-09 12:21 ` Gabriel C
2008-05-09 12:13 ` Gabriel C
1 sibling, 1 reply; 10+ messages in thread
From: Ingo Molnar @ 2008-05-09 9:42 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Gabriel C, Andrew Morton, linux-kernel, Rafael J. Wysocki,
Thomas Gleixner, John Stultz
* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> Subject: sched: fixup sched-clock offset
> From: Peter Zijlstra <a.p.zijlstra@chello.nl>
>
> It could happen that ktime doesn't start at 0.
applied, thanks Peter. I'm wondering which clocks do this - HPET
perhaps?
Ingo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: CONFIG_PRINTK_TIME broken on git HEAD ?
2008-05-09 9:39 ` Peter Zijlstra
2008-05-09 9:42 ` Ingo Molnar
@ 2008-05-09 12:13 ` Gabriel C
1 sibling, 0 replies; 10+ messages in thread
From: Gabriel C @ 2008-05-09 12:13 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Andrew Morton, linux-kernel, Rafael J. Wysocki, Ingo Molnar,
Thomas Gleixner, hinko.kocevar
Peter Zijlstra wrote:
> On Thu, 2008-05-08 at 13:21 +0200, Gabriel C wrote:
>
>>> Ok, so the issue is that the clock doesn't start at 0, but at:
>>> 4294014.506571 ?
>> At least on my box , yes.
>>
>
> Does this work for you?
No it does not , I still get :
....
[ 0.000000] PERCPU: Allocating 42756 bytes of per cpu data
[ 0.000000] NR_CPUS: 8, nr_cpu_ids: 4
[4294014.506571] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1010723
...
>
> ---
>
> Subject: sched: fixup sched-clock offset
> From: Peter Zijlstra <a.p.zijlstra@chello.nl>
>
> It could happen that ktime doesn't start at 0.
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> ---
> kernel/sched_clock.c | 16 +++++++++-------
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> Index: linux-2.6-2/kernel/sched_clock.c
> ===================================================================
> --- linux-2.6-2.orig/kernel/sched_clock.c
> +++ linux-2.6-2/kernel/sched_clock.c
> @@ -59,21 +59,23 @@ static inline struct sched_clock_data *c
> return &per_cpu(sched_clock_data, cpu);
> }
>
> +static __read_mostly u64 ktime_offset;
> +
> void sched_clock_init(void)
> {
> - u64 ktime_now = ktime_to_ns(ktime_get());
> - u64 now = 0;
> int cpu;
>
> + ktime_offset = ktime_to_ns(ktime_get());
> +
> for_each_possible_cpu(cpu) {
> struct sched_clock_data *scd = cpu_sdc(cpu);
>
> scd->lock = (raw_spinlock_t)__RAW_SPIN_LOCK_UNLOCKED;
> scd->prev_jiffies = jiffies;
> - scd->prev_raw = now;
> - scd->tick_raw = now;
> - scd->tick_gtod = ktime_now;
> - scd->clock = ktime_now;
> + scd->prev_raw = 0;
> + scd->tick_raw = 0;
> + scd->tick_gtod = 0;
> + scd->clock = 0;
> }
> }
>
> @@ -177,7 +179,7 @@ void sched_clock_tick(void)
> WARN_ON_ONCE(!irqs_disabled());
>
> now = sched_clock();
> - now_gtod = ktime_to_ns(ktime_get());
> + now_gtod = ktime_to_ns(ktime_get()) - ktime_offset;
>
> __raw_spin_lock(&scd->lock);
> __update_sched_clock(scd, now);
>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: CONFIG_PRINTK_TIME broken on git HEAD ?
2008-05-09 9:42 ` Ingo Molnar
@ 2008-05-09 12:21 ` Gabriel C
0 siblings, 0 replies; 10+ messages in thread
From: Gabriel C @ 2008-05-09 12:21 UTC (permalink / raw)
To: Ingo Molnar
Cc: Peter Zijlstra, Andrew Morton, linux-kernel, Rafael J. Wysocki,
Thomas Gleixner, John Stultz, hinko.kocevar
Ingo Molnar wrote:
> * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
>> Subject: sched: fixup sched-clock offset
>> From: Peter Zijlstra <a.p.zijlstra@chello.nl>
>>
>> It could happen that ktime doesn't start at 0.
>
> applied, thanks Peter. I'm wondering which clocks do this - HPET
> perhaps?
The box is using TSC clocksource right now , for some reason in >=2.6.25* kernels HPET registered to late.
http://lkml.org/lkml/2008/5/8/164
>
> Ingo
>
Gabriel
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2008-05-09 12:22 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-07 22:26 CONFIG_PRINTK_TIME broken on git HEAD ? Gabriel C
2008-05-07 22:41 ` Andrew Morton
2008-05-07 22:57 ` Gabriel C
2008-05-08 11:00 ` Gabriel C
2008-05-08 11:13 ` Peter Zijlstra
2008-05-08 11:21 ` Gabriel C
2008-05-09 9:39 ` Peter Zijlstra
2008-05-09 9:42 ` Ingo Molnar
2008-05-09 12:21 ` Gabriel C
2008-05-09 12:13 ` Gabriel C
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox