All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>,
	Suresh Siddha <suresh.b.siddha@intel.com>,
	"ananth@in.ibm.com" <ananth@in.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/4] x86: use dmi check to treat disabled cpus as hotplug cpus.
Date: Tue, 12 Jan 2010 10:46:24 +0100	[thread overview]
Message-ID: <20100112094624.GA24987@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.00.1001111906300.17145@localhost.localdomain>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Mon, 11 Jan 2010, Yinghai Lu wrote:
> >
> > some systems that have disable cpus entries because same
> >   BIOS will support 2 sockets and 4 sockets and more at
> >   same time, BIOS just leave some disable entries, but
> >   those system do not support cpu hotplug. we don't need
> >   treat disabled_cpus as hotplug cpus.
> >
> > so we can make nr_cpu_ids smaller and save more space
> >   (pcpu data allocations), and could make some systems run
> >   with logical flat instead of physical flat apic mode
> 
> .. but this one I detest.
> 
> We can't play games that depend on us always filling in some DMI table 
> correctly. Things need to "just work".
> 
> So while 1/4 looks fine, 2/4 looks fundamentally unacceptable.
> 
> Is the flat APIC mode really so important?

it's not important at all. When it's proven safe it's fine but it's clearly 
not unconditionally safe ...

> I would suggest a few alternatives:
> 
> Truly static:
> 
>  - only use that flat apic mode when you _know_ that you absolutely will 
>    never have more than 8 cpu's. Ie when CONFIG_NR_CPUS <= 8 (or, with 
>    1/3, when nr_cpu_ids <= 8) and/or when <= 8 CPU's were detected, and 
>    CPU hotplug is disabled entirely.
> 
> Slightly more intelligent:
> 
>  - Look at the ACPI socket count, and hey, if it says it might have more 
>    sockets - whether they are really hotplug or not, don't use flat mode, 
>    because we simply don't know. But do _not_ do some kind of DMI table to 
>    say one way or the other.
> 
> And if it's _really_ important:
> 
>  - if flat mode is so important that you want to enable it whenever 
>    possible, what about enabling/disabling it dynamically at CPU hotplug 
>    time? That does sound _very_ painful, but it's still better than having 
>    to maintain some list of all systems that can ever hot-plug. 
> 
> Hmm?

I'd go for #1. If the (modest) micro-performance advantages of flat delivery 
matter to a hardware vendor the system/BIOS can be built in a way to trigger 
the optimization. But even single socket systems are quickly running out of 
the space of 8 APIC ids so the relevance is dwindling ...

	Ingo

  parent reply	other threads:[~2010-01-12  9:47 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-12  2:48 [RFC PATCH 1/4] use nr_cpus= to set nr_cpu_ids early Yinghai Lu
2010-01-12  2:48 ` [RFC PATCH 3/4] x86: using logical flat for amd cpu too Yinghai Lu
2010-01-12  3:16   ` Linus Torvalds
2010-01-12  8:47     ` Yinghai Lu
2010-01-12  8:27   ` Ananth N Mavinakayanahalli
2010-01-12 22:50     ` H. Peter Anvin
2010-01-13  4:53       ` Ananth N Mavinakayanahalli
2010-01-12  2:48 ` [RFC PATCH 4/4] x86: according to nr_cpu_ids to decide if need to leave logical flat Yinghai Lu
2010-01-12  3:20   ` Linus Torvalds
2010-01-12  8:50     ` Yinghai Lu
2010-01-12  2:48 ` [RFC PATCH 2/4] x86: use dmi check to treat disabled cpus as hotplug cpus Yinghai Lu
2010-01-12  3:13   ` Linus Torvalds
2010-01-12  8:59     ` Yinghai Lu
2010-01-12 15:19       ` Linus Torvalds
2010-01-12 17:54         ` Suresh Siddha
2010-01-12 18:13         ` Yinghai Lu
2010-01-12 18:24           ` Suresh Siddha
2010-01-12 19:19             ` Yinghai Lu
2010-01-12  9:15     ` Yinghai Lu
2010-01-12  9:46     ` Ingo Molnar [this message]
2010-01-12 16:14     ` Valdis.Kletnieks
2010-01-12 16:26       ` Linus Torvalds
2010-01-12 17:17         ` Valdis.Kletnieks
2010-01-12  3:06 ` [RFC PATCH 1/4] use nr_cpus= to set nr_cpu_ids early Linus Torvalds

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=20100112094624.GA24987@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=yinghai@kernel.org \
    /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.