public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Luming Yu <luming.yu@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	suresh.b.siddha@intel.com, venkatesh.pallipadi@intel.com,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [RFC patch] Use IPI_shortcut for lapic timer broadcast
Date: Mon, 29 Jun 2009 10:16:15 +0200	[thread overview]
Message-ID: <20090629081615.GB571@elte.hu> (raw)
In-Reply-To: <3877989d0906290104q11a767b6qcc1acc4c2d1feba6@mail.gmail.com>


* Luming Yu <luming.yu@gmail.com> wrote:

> On Mon, Jun 29, 2009 at 3:20 PM, Ingo Molnar<mingo@elte.hu> wrote:
> >
> > * Luming Yu <luming.yu@gmail.com> wrote:
> >
> >> Hello,
> >>
> >> We need to use IPI shortcut to send lapic timer broadcast
> >> to avoid the latency of sending IPI one bye one on systems with many
> >> logical processors when NO_HZ is disabled.
> >> Without this patch,I have seen upstream kernel with RHEL 5 kernel
> >> config boot hang .
> >
> > hm, that might be a valid optimization - but why does the lack of
> > this optimization result in a hang?
> 
> It is hang caused by kernel code for work around lapic-timer-stop 
> issue. With HZ=1000, and a lot of cpus (eg. 64 logical cpus), cpu 
> 0 will be busy working on send TIMER IPI instead of making 
> progress in boot (right after deep-C-state has been used).

that's a bit weird. With HZ=1000 we have 1000 usecs between each 
timer tick. Assuming a CPU sends to a lot of CPUs (64 logical CPUs) 
that means that each IPI takes more than ~15 microseconds to 
process. On what hardware/platform can this happen realistically?

	Ingo

  reply	other threads:[~2009-06-29  8:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-29  6:47 [RFC patch] Use IPI_shortcut for lapic timer broadcast Luming Yu
2009-06-29  7:20 ` Ingo Molnar
2009-06-29  8:04   ` Luming Yu
2009-06-29  8:16     ` Ingo Molnar [this message]
2009-06-29  8:21       ` Luming Yu
2009-06-29  8:30         ` Ingo Molnar
2009-06-29  8:43           ` Luming Yu
2009-06-29  9:15             ` Ingo Molnar
2009-06-29 14:01             ` Arjan van de Ven
2009-06-29 20:34 ` Pallipadi, Venkatesh
2009-06-30  7:01   ` Luming Yu
2009-07-03  0:23     ` Pallipadi, Venkatesh
2009-07-03  2:04       ` Luming Yu

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=20090629081615.GB571@elte.hu \
    --to=mingo@elte.hu \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luming.yu@gmail.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=venkatesh.pallipadi@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox