Re: [git pull] x86/hrtimer/acpi fixes
* Guillaume Chazarain <[EMAIL PROTECTED]> wrote: > On Dec 9, 2007 7:01 PM, Pavel Machek <[EMAIL PROTECTED]> wrote: > > > + * ns += offset to avoid sched_clock jumps with cpufreq > > > + * > > > * [EMAIL PROTECTED] "math is hard, lets go shopping!" > > > */ > > > > Did john add the 'ns+=' or do comments need reorder? > > I added it, but I think it needs to be removed as now the offset is > maintained by the scheduler in __update_rq_clock(). yeah, and it's already removed in latest x86.git. Ingo -- 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/
Re: [git pull] x86/hrtimer/acpi fixes
On Dec 9, 2007 7:01 PM, Pavel Machek <[EMAIL PROTECTED]> wrote: > > + * ns += offset to avoid sched_clock jumps with cpufreq > > + * > > * [EMAIL PROTECTED] "math is hard, lets go shopping!" > > */ > > Did john add the 'ns+=' or do comments need reorder? I added it, but I think it needs to be removed as now the offset is maintained by the scheduler in __update_rq_clock(). Thanks. -- Guillaume -- 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/
Re: [git pull] x86/hrtimer/acpi fixes
Hi! > @@ -78,15 +79,35 @@ EXPORT_SYMBOL_GPL(check_tsc_unstable); > * cyc2ns_scale is limited to 10^6 * 2^10, which fits in 32 bits. > * ([EMAIL PROTECTED]) > * > + * ns += offset to avoid sched_clock jumps with cpufreq > + * > * [EMAIL PROTECTED] "math is hard, lets go shopping!" > */ Did john add the 'ns+=' or do comments need reorder? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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/
Re: [git pull] x86/hrtimer/acpi fixes
* Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > On Fri, 2007-12-07 at 20:59 +0100, Ingo Molnar wrote: > > * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > > > > > > Nope, it doesn't still getting "delay" and "xrun" messages galore. > > > > > > Attached: configuration and dmesg output booting with idle=poll, > > > reconfirmed that that makes the delay and xrun messages go away. > > > > could you try the rolled up patch of various fixlets, ontop of > > current -git? (it might even apply to -rc4) It includes some more > > stuff beyond the ones in the pull request. (still being > > tested/reviewed) > > I'll try but it will take me a while to figure git and do a package > build of it... if you want to try a vanilla kernel package then pick up the kernel package from Fedora rawhide - this fixlet should show up there within a couple of days, Dave Jones is doing a really nice job of keeping up with latest -git. (and the Fedora kernel has hrtimers and dynticks enabled.) Ingo -- 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/
Re: [git pull] x86/hrtimer/acpi fixes
On Fri, 2007-12-07 at 20:59 +0100, Ingo Molnar wrote: > * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > > > > Nope, it doesn't still getting "delay" and "xrun" messages galore. > > > > Attached: configuration and dmesg output booting with idle=poll, > > reconfirmed that that makes the delay and xrun messages go away. > > could you try the rolled up patch of various fixlets, ontop of current > -git? (it might even apply to -rc4) It includes some more stuff beyond > the ones in the pull request. (still being tested/reviewed) I'll try but it will take me a while to figure git and do a package build of it... -- Fernando -- 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/
Re: [git pull] x86/hrtimer/acpi fixes
* Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote:
> > Nope, it doesn't still getting "delay" and "xrun" messages galore.
>
> Attached: configuration and dmesg output booting with idle=poll,
> reconfirmed that that makes the delay and xrun messages go away.
could you try the rolled up patch of various fixlets, ontop of current
-git? (it might even apply to -rc4) It includes some more stuff beyond
the ones in the pull request. (still being tested/reviewed)
Ingo
Index: linux/arch/arm/kernel/time.c
===
--- linux.orig/arch/arm/kernel/time.c
+++ linux/arch/arm/kernel/time.c
@@ -79,17 +79,6 @@ static unsigned long dummy_gettimeoffset
}
#endif
-/*
- * An implementation of printk_clock() independent from
- * sched_clock(). This avoids non-bootable kernels when
- * printk_clock is enabled.
- */
-unsigned long long printk_clock(void)
-{
- return (unsigned long long)(jiffies - INITIAL_JIFFIES) *
- (10 / HZ);
-}
-
static unsigned long next_rtc_update;
/*
Index: linux/arch/ia64/kernel/time.c
===
--- linux.orig/arch/ia64/kernel/time.c
+++ linux/arch/ia64/kernel/time.c
@@ -344,33 +344,6 @@ udelay (unsigned long usecs)
}
EXPORT_SYMBOL(udelay);
-static unsigned long long ia64_itc_printk_clock(void)
-{
- if (ia64_get_kr(IA64_KR_PER_CPU_DATA))
- return sched_clock();
- return 0;
-}
-
-static unsigned long long ia64_default_printk_clock(void)
-{
- return (unsigned long long)(jiffies_64 - INITIAL_JIFFIES) *
- (10/HZ);
-}
-
-unsigned long long (*ia64_printk_clock)(void) = &ia64_default_printk_clock;
-
-unsigned long long printk_clock(void)
-{
- return ia64_printk_clock();
-}
-
-void __init
-ia64_setup_printk_clock(void)
-{
- if (!(sal_platform_features & IA64_SAL_PLATFORM_FEATURE_ITC_DRIFT))
- ia64_printk_clock = ia64_itc_printk_clock;
-}
-
/* IA64 doesn't cache the timezone */
void update_vsyscall_tz(void)
{
Index: linux/arch/x86/kernel/process_32.c
===
--- linux.orig/arch/x86/kernel/process_32.c
+++ linux/arch/x86/kernel/process_32.c
@@ -113,10 +113,19 @@ void default_idle(void)
smp_mb();
local_irq_disable();
- if (!need_resched())
+ if (!need_resched()) {
+ ktime_t t0, t1;
+ u64 t0n, t1n;
+
+ t0 = ktime_get();
+ t0n = ktime_to_ns(t0);
safe_halt();/* enables interrupts racelessly */
- else
- local_irq_enable();
+ local_irq_disable();
+ t1 = ktime_get();
+ t1n = ktime_to_ns(t1);
+ sched_clock_idle_wakeup_event(t1n - t0n);
+ }
+ local_irq_enable();
current_thread_info()->status |= TS_POLLING;
} else {
/* loop is done by the caller */
Index: linux/arch/x86/kernel/tsc_32.c
===
--- linux.orig/arch/x86/kernel/tsc_32.c
+++ linux/arch/x86/kernel/tsc_32.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
@@ -78,15 +79,35 @@ EXPORT_SYMBOL_GPL(check_tsc_unstable);
* cyc2ns_scale is limited to 10^6 * 2^10, which fits in 32 bits.
* ([EMAIL PROTECTED])
*
+ * ns += offset to avoid sched_clock jumps with cpufreq
+ *
* [EMAIL PROTECTED] "math is hard, lets go shopping!"
*/
-unsigned long cyc2ns_scale __read_mostly;
-#define CYC2NS_SCALE_FACTOR 10 /* 2^10, carefully chosen */
+DEFINE_PER_CPU(unsigned long, cyc2ns);
-static inline void set_cyc2ns_scale(unsigned long cpu_khz)
+static void set_cyc2ns_scale(unsigned long cpu_khz, int cpu)
{
- cyc2ns_scale = (100 << CYC2NS_SCALE_FACTOR)/cpu_khz;
+ unsigned long flags, prev_scale, *scale;
+ unsigned long long tsc_now, ns_now;
+
+ local_irq_save(flags);
+ sched_clock_idle_sleep_event();
+
+ scale = &per_cpu(cyc2ns, cpu);
+
+ rdtscll(tsc_now);
+ ns_now = __cycles_2_ns(tsc_now);
+
+ prev_scale = *scale;
+ if (cpu_khz)
+ *scale = (NSEC_PER_MSEC << CYC2NS_SCALE_FACTOR)/cpu_khz;
+
+ /*
+* Start smoothly with the new frequency:
+*/
+ sched_clock_idle_wakeup_event(0);
+ local_irq_restore(flags);
}
/*
@@ -239,7 +260,9 @@ time_cpufreq_notifier(struct notifier_bl
ref_freq, freq->new);
if (!(freq->flags & CPUFREQ_CONST_LOOPS)) {
tsc_khz = cpu_khz;
- set_cyc2ns_scale(cpu_khz);
+ preempt_disable();
+
Re: [git pull] x86/hrtimer/acpi fixes
On Fri, 2007-12-07 at 19:59 +0100, Ingo Molnar wrote: > * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > > > Ingo, I was about to post about timer problems in 2.6.23.9+rt12 when I > > saw this. Would this be related / should I test / will this solve > > everything? :-) > > > > What I'm seeing is jack "delays" that go away if I boot with > > "idle=poll", just like it was happening a long time ago. Smells like > > 'time of day' glitches when the process switches cpus (this is on a > > dual core intel laptop). > > does it go away with hpet=disable as well? If yes then there could be a > relation. If not then it's something else and we need to debug it. Nope, it doesn't still getting "delay" and "xrun" messages galore. -- Fernando -- 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/
Re: [git pull] x86/hrtimer/acpi fixes
* Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > Ingo, I was about to post about timer problems in 2.6.23.9+rt12 when I > saw this. Would this be related / should I test / will this solve > everything? :-) > > What I'm seeing is jack "delays" that go away if I boot with > "idle=poll", just like it was happening a long time ago. Smells like > 'time of day' glitches when the process switches cpus (this is on a > dual core intel laptop). does it go away with hpet=disable as well? If yes then there could be a relation. If not then it's something else and we need to debug it. Ingo -- 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/
Re: [git pull] x86/hrtimer/acpi fixes
On Fri, 2007-12-07 at 19:36 +0100, Ingo Molnar wrote:
> Linus, please pull the latest x86 git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
>
> This contains 3 x86/hrtimer/hpet/ACPI fixes from Thomas: the ACPI fix
> has been ACK-ed by Venki. Build and boot tested on various boxes.
Ingo, I was about to post about timer problems in 2.6.23.9+rt12 when I
saw this. Would this be related / should I test / will this solve
everything? :-)
What I'm seeing is jack "delays" that go away if I boot with
"idle=poll", just like it was happening a long time ago. Smells like
'time of day' glitches when the process switches cpus (this is on a dual
core intel laptop).
Does not happen in 2.6.22.10 + rt9 - well, I do see very occassional
delay warnings there as well.
I also see occassional complete hangs but I don't have a way of knowing
what triggers that.
-- Fernando
> -->
> Thomas Gleixner (3):
> hrtimers: avoid overflow for large relative timeouts
> clockevents: warn once when program_event() is called with negative
> expiry
> ACPI: move timer broadcast before busmaster disable
>
> drivers/acpi/processor_idle.c | 19 ++-
> kernel/hrtimer.c |8
> kernel/time/clockevents.c |5 +
> 3 files changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> index b1fbee3..2fe34cc 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -531,6 +531,11 @@ static void acpi_processor_idle(void)
>
> case ACPI_STATE_C3:
> /*
> + * Must be done before busmaster disable as we might
> + * need to access HPET !
> + */
> + acpi_state_timer_broadcast(pr, cx, 1);
> + /*
>* disable bus master
>* bm_check implies we need ARB_DIS
>* !bm_check implies we need cache flush
> @@ -557,7 +562,6 @@ static void acpi_processor_idle(void)
> /* Get start time (ticks) */
> t1 = inl(acpi_gbl_FADT.xpm_timer_block.address);
> /* Invoke C3 */
> - acpi_state_timer_broadcast(pr, cx, 1);
> /* Tell the scheduler that we are going deep-idle: */
> sched_clock_idle_sleep_event();
> acpi_cstate_enter(cx);
> @@ -1401,9 +1405,6 @@ static int acpi_idle_enter_simple(struct cpuidle_device
> *dev,
> if (acpi_idle_suspend)
> return(acpi_idle_enter_c1(dev, state));
>
> - if (pr->flags.bm_check)
> - acpi_idle_update_bm_rld(pr, cx);
> -
> local_irq_disable();
> current_thread_info()->status &= ~TS_POLLING;
> /*
> @@ -1418,13 +1419,21 @@ static int acpi_idle_enter_simple(struct
> cpuidle_device *dev,
> return 0;
> }
>
> + /*
> + * Must be done before busmaster disable as we might need to
> + * access HPET !
> + */
> + acpi_state_timer_broadcast(pr, cx, 1);
> +
> + if (pr->flags.bm_check)
> + acpi_idle_update_bm_rld(pr, cx);
> +
> if (cx->type == ACPI_STATE_C3)
> ACPI_FLUSH_CPU_CACHE();
>
> t1 = inl(acpi_gbl_FADT.xpm_timer_block.address);
> /* Tell the scheduler that we are going deep-idle: */
> sched_clock_idle_sleep_event();
> - acpi_state_timer_broadcast(pr, cx, 1);
> acpi_idle_do_entry(cx);
> t2 = inl(acpi_gbl_FADT.xpm_timer_block.address);
>
> diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
> index 22a2514..e65dd0b 100644
> --- a/kernel/hrtimer.c
> +++ b/kernel/hrtimer.c
> @@ -850,6 +850,14 @@ hrtimer_start(struct hrtimer *timer, ktime_t tim, const
> enum hrtimer_mode mode)
> #ifdef CONFIG_TIME_LOW_RES
> tim = ktime_add(tim, base->resolution);
> #endif
> + /*
> + * Careful here: User space might have asked for a
> + * very long sleep, so the add above might result in a
> + * negative number, which enqueues the timer in front
> + * of the queue.
> + */
> + if (tim.tv64 < 0)
> + tim.tv64 = KTIME_MAX;
> }
> timer->expires = tim;
>
> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
> index 822beeb..5fb139f 100644
> --- a/kernel/time/clockevents.c
> +++ b/kernel/time/clockevents.c
> @@ -78,6 +78,11 @@ int clockevents_program_event(struct clock_event_device
> *dev, ktime_t expires,
> unsigned long long clc;
> int64_t delta;
>
> + if (unlikely(expires.tv64 < 0)) {
> + WARN_ON_ONCE(1);
> + return -ETIME;
> + }
> +
> delta = ktime_to_ns(ktime_sub(expires, now));
>
> if (delta <= 0)
> --
> 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://
