All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: nohz and strange sleep latencies
Date: Thu, 22 Nov 2007 11:09:41 +0100	[thread overview]
Message-ID: <20071122100941.GA1724@elf.ucw.cz> (raw)
In-Reply-To: <20071120225246.GA24380@elte.hu>

Hi!

> > > > > and send us the output? (Enabling CONFIG_TIMER_STATS, 
> > > > > CONFIG_SCHED_DEBUG and CONFIG_SCHEDSTATS would maximize the amount 
> > > > > of information.)
> > > > 
> > > > This was w/o hpet=disable . Do you want me to test with hpet=disable?
> > > 
> > > no, this is fine. You've got a hpet clockevents driver and two lapic 
> > > drivers:
> > > 
> > > Clock Event Device: hpet
> > >  set_next_event: hpet_legacy_next_event
> > >  set_mode:       hpet_legacy_set_mode
> > >  event_handler:  tick_handle_oneshot_broadcast
> > > 
> > > Clock Event Device: lapic
> > >  set_next_event: lapic_next_event
> > >  set_mode:       lapic_timer_setup
> > >  event_handler:  hrtimer_interrupt
> > > 
> > > Clock Event Device: lapic
> > >  set_next_event: lapic_next_event
> > >  set_mode:       lapic_timer_setup
> > >  event_handler:  hrtimer_interrupt
> > > 
> > > to me this has the feeling of lapic breakage in C2 mode. Does it get any 
> > > better if you boot with 'nolapic'? (but that might in turn turn off 
> > > high-res timers and nohz in essence) Thomas, any ideas?
> > 
> > Hmm, lapic is considered unstable in c2 by default. You have to tell 
> > the kernel that you trust it in C2 on the command line.
> 
> yeah, i was wondering about that too. ACPI enumerated them properly at a 
> certain stage:
> 
>  ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
>  ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3])
> 
> but perhaps somehow we miss this fact and fail to turn off the lapic 
> clockevents drivers?

I tried to add nolapic_timer manually, and that helped, but:

checking TSC synchronization [CPU#0 -> CPU#1]:
Measured 627605 cycles TSC warp between CPUs, turning off TSC clock.
Marking TSC unstable due to: check_tsc_sync_source failed.
Brought up 2 CPUs
CPU0 attaching sched-domain:
 domain 0: span 3
  groups: 1 2
CPU1 attaching sched-domain:
 domain 0: span 3
  groups: 2 1
net_namespace: 64 bytes
...
Bluetooth: HCI socket layer initialized
ACPI: RTC can wake from S4
Time: hpet clocksource has been installed.
Clockevents: could not switch to one-shot mode:<6>Clockevents: could
not switch to one-shot mode: lapic is not functional.
Could not switch to high resolution mode on CPU 1
 lapic is not functional.
Could not switch to high resolution mode on CPU 0
system 00:00: iomem range 0x0-0x9ffff could not be reserved

...and result is nohz is not functional :-(.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2007-11-22 10:09 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-19 20:31 nohz and strange sleep latencies Pavel Machek
2007-11-19 20:55 ` Ingo Molnar
2007-11-19 21:11   ` Pavel Machek
2007-11-20  8:57     ` Ingo Molnar
2007-11-20  9:05       ` Ingo Molnar
2007-11-20 10:54       ` Pavel Machek
2007-11-20 20:54         ` Ingo Molnar
2007-11-20 22:48           ` Thomas Gleixner
2007-11-20 22:52             ` Ingo Molnar
2007-11-22 10:09               ` Pavel Machek [this message]
2007-11-22 18:51               ` Pavel Machek
2007-11-22 18:52               ` Pavel Machek
2007-11-22 20:29                 ` Thomas Gleixner
2007-11-23 12:22                   ` Pavel Machek
2007-11-24 22:29                   ` Pavel Machek
2007-11-24 22:40                   ` Pavel Machek
2007-11-24 23:29                     ` Rafael J. Wysocki
2007-11-24 23:35                       ` Rafael J. Wysocki
2007-11-25 21:51                       ` Thomas Gleixner
2007-11-25 20:25                   ` [patch] " Pavel Machek
2007-11-25 21:42                     ` Thomas Gleixner
2007-11-26 11:54                   ` Pavel Machek
2007-11-20  9:44 ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071122100941.GA1724@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.