public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Andi Kleen <ak@suse.de>
Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>,
	Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, ashok.raj@intel.com
Subject: Re: [patch] genapic: optimize & fix APIC mode setup
Date: Mon, 13 Nov 2006 15:05:20 +0100	[thread overview]
Message-ID: <20061113140520.GA8111@elte.hu> (raw)
In-Reply-To: <200611131008.37810.ak@suse.de>


* Andi Kleen <ak@suse.de> wrote:

> > Had i ever noticed this hack in the first place i would have NAK-ed 
> > it. There is a fundamental design friction of a high-level feature 
> > like HOTPLUG_CPU /requiring/ a fundamental change to the lowlevel 
> > IRQ delivery mode!
> 
> Well to be honest masked mode isn't that useful anyways. It's only 
> theoretical advantage would be a bit more performance for multicast 
> IPIs, but Ashok did benchmarks and it didn't make any significant 
> difference. [...]

this argument is false for at least two reasons. Firstly, i can show you 
a 1000 small changes that wont be measurable individually but that as a 
summary effect can degrade the kernel substantially.

Secondly, in the physical case, /all/ IPI sending goes through this 
code:

        for_each_cpu_mask(query_cpu, mask) {

yes, even the single-IPI calls which give the overwhelming majority of 
the use of IPIs. Even on systems that have only 2 CPUs to begin with. 
This should be measurable.

> [...] With that I prefer to use always the same mode for small and 
> large systems. Ok should probably drop the ifdef and just always use 
> physical mode.

you are still not getting it i think. The IO-APIC is still in logical 
delivery mode on small systems, and we very much make use of this fact 
by using LowestPrio messages (that current CPUs started to support 
again). The switching to physical mode is dangerous because it creates 
'mixed' APIC messages (physical and logical targeted messages as well) - 
which 'mixed mode' is notorious for erratas both in the CPU and in the 
chipset. (I strongly suspect that my eth timeouts are due to that.) 

Combine this with the fact that /normally/ we default to logical mode, 
the basis of your position is quite puzzling to me.

the right solution is to use pure physical mode (both local APIC and 
IO-APIC) only on large systems, and to use pure logical mode on small 
systems - maybe with the combination of clustered mode as well.

and that's precisely what my patch achieves ...

> > Such a requirement is broken and just serves to hide a flaw in the 
> > hotplug design - which flaw would trigger on i386 /anyway/, because 
> > i386 still uses logical delivery mode for APIC IPIs.
> 
> i386 cpu hotplug is somewhat broken anyways, but it should be fixed 
> there too eventually. But some very old chipsets don't seem to support 
> physical properly so it wasn't changed there.

as i said it before, what you are suggesting is not a 'fix', it's a 
workaround for a design flaw in the hotplug code which flaw is hitting 
us in other places and architectures anyway, and which workaround makes 
us use an inferior IRQ delivery method on small systems ...

	Ingo

  reply	other threads:[~2006-11-13 14:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-11 15:14 [patch] genapic: optimize & fix APIC mode setup Ingo Molnar
2006-11-11 15:20 ` Andi Kleen
2006-11-11 15:27   ` Ingo Molnar
2006-11-11 15:39   ` Ingo Molnar
2006-11-13  1:50   ` Siddha, Suresh B
2006-11-13  2:32     ` Andi Kleen
2006-11-13  8:16       ` Ingo Molnar
2006-11-13  9:08         ` Andi Kleen
2006-11-13 14:05           ` Ingo Molnar [this message]
2006-11-13 14:29             ` Andi Kleen
2006-11-13 15:04               ` Ingo Molnar
2006-11-13 16:10                 ` Andi Kleen
2006-11-13 16:32                   ` Ingo Molnar
2006-11-13 18:03                     ` Siddha, Suresh B
2006-11-13 18:42                       ` Ingo Molnar
2006-11-13 18:30                         ` Siddha, Suresh B
2006-11-13 19:04                           ` Ingo Molnar
2006-11-13 18:58                             ` Siddha, Suresh B
2006-11-13 19:31                         ` Ashok Raj
2006-11-13 19:08                     ` Ingo Molnar
2006-11-13 14:14           ` Ingo Molnar
2006-11-13  8:43     ` Ingo Molnar
2006-11-13 17:34       ` Siddha, Suresh B

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=20061113140520.GA8111@elte.hu \
    --to=mingo@elte.hu \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=ashok.raj@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suresh.b.siddha@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