Regression: Machine runs really slowly after commit f12a15be
in [Kernel]
|
Prev: Some cleanups
Next: Document sysfs entries
From: john stultz on 9 Aug 2010 15:10 On Sat, 2010-08-07 at 16:15 +0300, Priit Laes wrote: > Following commit makes my Dell Latitude D610 machine (x86_32) run really-really slow... > > f12a15be63d1de9a35971f35f06b73088fa25c3a is the first bad commit > commit f12a15be63d1de9a35971f35f06b73088fa25c3a > Author: John Stultz <johnstul(a)us.ibm.com> On Sat, 2010-08-07 at 23:04 +0200, Alexey Fisher wrote: > Hallo John, > i have regression after commit f12a15be6. > With this patch my netbook (Asus Eeepc 1005) starting really slow. It > looks like printk comes 1/min. Hi Priit, Alexey, Thanks so much for the testing and bisecting the issue down! Could you both please provide the output of: cat /sys/devices/system/clocksource/clocksource0/current_clocksource cat /sys/devices/system/clocksource/clocksource0/available_clocksource thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alexey Fisher on 9 Aug 2010 15:40 Am Montag, den 09.08.2010, 12:01 -0700 schrieb john stultz: > On Sat, 2010-08-07 at 16:15 +0300, Priit Laes wrote: > > Following commit makes my Dell Latitude D610 machine (x86_32) run really-really slow... > > > > f12a15be63d1de9a35971f35f06b73088fa25c3a is the first bad commit > > commit f12a15be63d1de9a35971f35f06b73088fa25c3a > > Author: John Stultz <johnstul(a)us.ibm.com> > > On Sat, 2010-08-07 at 23:04 +0200, Alexey Fisher wrote: > > Hallo John, > > i have regression after commit f12a15be6. > > With this patch my netbook (Asus Eeepc 1005) starting really slow. It > > looks like printk comes 1/min. > > Hi Priit, Alexey, > Thanks so much for the testing and bisecting the issue down! > > Could you both please provide the output of: > cat /sys/devices/system/clocksource/clocksource0/current_clocksource > cat /sys/devices/system/clocksource/clocksource0/available_clocksource cat /sys/devices/system/clocksource/clocksource0/current_clocksource hpet cat /sys/devices/system/clocksource/clocksource0/available_clocksource hpet acpi_pm -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Priit Laes on 9 Aug 2010 15:50 Ühel kenal päeval, E, 2010-08-09 kell 12:01, kirjutas john stultz: > On Sat, 2010-08-07 at 16:15 +0300, Priit Laes wrote: > > Following commit makes my Dell Latitude D610 machine (x86_32) run really-really slow... > > > > f12a15be63d1de9a35971f35f06b73088fa25c3a is the first bad commit > > commit f12a15be63d1de9a35971f35f06b73088fa25c3a > > Author: John Stultz <johnstul(a)us.ibm.com> > > Could you both please provide the output of: > cat /sys/devices/system/clocksource/clocksource0/current_clocksource > cat /sys/devices/system/clocksource/clocksource0/available_clocksource This is with kernel 2.6 cat /sys/devices/system/clocksource/clocksource0/current_clocksource hpet cat /sys/devices/system/clocksource/clocksource0/available_clocksource hpet acpi_pm Päikest, Priit ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: john stultz on 9 Aug 2010 16:00 On Mon, 2010-08-09 at 21:38 +0200, Alexey Fisher wrote: > cat /sys/devices/system/clocksource/clocksource0/current_clocksource > hpet > > cat /sys/devices/system/clocksource/clocksource0/available_clocksource > hpet acpi_pm On Mon, 2010-08-09 at 22:43 +0300, Priit Laes wrote: > cat /sys/devices/system/clocksource/clocksource0/current_clocksource > hpet > cat /sys/devices/system/clocksource/clocksource0/available_clocksource > hpet acpi_pm Ok. Good. Chris Wilson has created the following patch which should hopefully resolve this issue. It would be great if you could try booting with it to verify that there are no other problems lurking here. Thanks again for the great bug reporting! thanks -john From: Chris Wilson <chris(a)chris-wilson.co.uk> Subject: [PATCH] x86/hpet: Use the FSEC_PER_SEC constant for femto-second periods The current computation, introduced with f12a15be63, of FSEC_PER_SEC using the multiplication of (FSEC_PER_NSEC * NSEC_PER_SEC) is performed only with 32bit integers on small machines, resulting in an overflow and a *very* short intervals being programmed. An interrupt storm follows. Note that we also have to specify FSEC_PER_SEC as being long long to overcome the same limitations. Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Signed-off-by: John Stultz <johnstul(a)us.ibm.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> --- arch/x86/kernel/hpet.c | 4 ++-- include/linux/time.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index 33dbcc4..351f9c0 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -582,7 +582,7 @@ static void init_one_hpet_msi_clockevent(struct hpet_dev *hdev, int cpu) * scaled math multiplication factor for nanosecond to hpet tick * conversion. */ - hpet_freq = 1000000000000000ULL; + hpet_freq = FSEC_PER_SEC; do_div(hpet_freq, hpet_period); evt->mult = div_sc((unsigned long) hpet_freq, NSEC_PER_SEC, evt->shift); @@ -837,7 +837,7 @@ static int hpet_clocksource_register(void) * cyc/sec = FSEC_PER_SEC/hpet_period(fsec/cyc) * cyc/sec = (FSEC_PER_NSEC * NSEC_PER_SEC)/hpet_period */ - hpet_freq = FSEC_PER_NSEC * NSEC_PER_SEC; + hpet_freq = FSEC_PER_SEC; do_div(hpet_freq, hpet_period); clocksource_register_hz(&clocksource_hpet, (u32)hpet_freq); diff --git a/include/linux/time.h b/include/linux/time.h index cb34e35..1261270 100644 --- a/include/linux/time.h +++ b/include/linux/time.h @@ -38,7 +38,7 @@ extern struct timezone sys_tz; #define NSEC_PER_MSEC 1000000L #define USEC_PER_SEC 1000000L #define NSEC_PER_SEC 1000000000L -#define FSEC_PER_SEC 1000000000000000L +#define FSEC_PER_SEC 1000000000000000LL #define TIME_T_MAX (time_t)((1UL << ((sizeof(time_t) << 3) - 1)) - 1) -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alexey Fisher on 9 Aug 2010 16:20 On Mo, 2010-08-09 at 12:51 -0700, john stultz wrote: > On Mon, 2010-08-09 at 21:38 +0200, Alexey Fisher wrote: > > cat /sys/devices/system/clocksource/clocksource0/current_clocksource > > hpet > > > > cat /sys/devices/system/clocksource/clocksource0/available_clocksource > > hpet acpi_pm > > > On Mon, 2010-08-09 at 22:43 +0300, Priit Laes wrote: > > cat /sys/devices/system/clocksource/clocksource0/current_clocksource > > hpet > > cat /sys/devices/system/clocksource/clocksource0/available_clocksource > > hpet acpi_pm > > > Ok. Good. Chris Wilson has created the following patch which should > hopefully resolve this issue. It would be great if you could try booting > with it to verify that there are no other problems lurking here. > > Thanks again for the great bug reporting! > > thanks > -john > > > From: Chris Wilson <chris(a)chris-wilson.co.uk> > Subject: [PATCH] x86/hpet: Use the FSEC_PER_SEC constant for femto-second > periods > > The current computation, introduced with f12a15be63, of FSEC_PER_SEC using > the multiplication of (FSEC_PER_NSEC * NSEC_PER_SEC) is performed only > with 32bit integers on small machines, resulting in an overflow and a > *very* short intervals being programmed. An interrupt storm follows. > > Note that we also have to specify FSEC_PER_SEC as being long long to > overcome the same limitations. > > Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> > Signed-off-by: John Stultz <johnstul(a)us.ibm.com> > Cc: Thomas Gleixner <tglx(a)linutronix.de> > --- This patch work for me. At least it boot. Tank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Pages: 1 Prev: Some cleanups Next: Document sysfs entries |