LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Eric Dumazet <dada1@cosmosbay.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Mike Travis <travis@sgi.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>, Andi Kleen <ak@suse.de>,
	Christoph Lameter <clameter@sgi.com>,
	Jack Steiner <steiner@sgi.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Andy Whitcroft <apw@shadowen.org>,
	Randy Dunlap <rdunlap@xenotime.net>,
	Joel Schopp <jschopp@austin.ibm.com>
Subject: Re: [PATCH 1/2] x86_64: Fold pda into per cpu area v3
Date: Wed, 20 Feb 2008 14:16:59 +0100	[thread overview]
Message-ID: <20080220141659.45ec31fa.dada1@cosmosbay.com> (raw)
In-Reply-To: <20080220120747.GA13695@elte.hu>

On Wed, 20 Feb 2008 13:07:47 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Mike Travis <travis@sgi.com> wrote:
> 
> >   * Declare the pda as a per cpu variable. This will move the pda area
> >     to an address accessible by the x86_64 per cpu macros.  
> >     Subtraction of __per_cpu_start will make the offset based from the 
> >     beginning of the per cpu area.  Since %gs is pointing to the pda, 
> >     it will then also point to the per cpu variables and can be 
> >     accessed thusly:
> > 
> > 	%gs:[&per_cpu_xxxx - __per_cpu_start]
> 
> randconfig QA on x86.git found a crash on x86.git#testing with 
> nmi_watchdog=2 (config attached) - and i bisected it down to this patch.
> 
> config and crashlog attached. You can pick up x86.git#testing via:
> 
>   http://people.redhat.com/mingo/x86.git/README
> 
> (since i had to hand-merge the patch when integrating it, i've attached 
> the merged version below.)
> 
> 	Ingo
> 
> -------------->
> Subject: x86_64: Fold pda into per cpu area v3
> From: Mike Travis <travis@sgi.com>
> Date: Tue, 19 Feb 2008 12:33:36 -0800
> 
>   * Declare the pda as a per cpu variable. This will move the pda area
>     to an address accessible by the x86_64 per cpu macros.  Subtraction
>     of __per_cpu_start will make the offset based from the beginning
>     of the per cpu area.  Since %gs is pointing to the pda, it will
>     then also point to the per cpu variables and can be accessed thusly:
> 
> 	%gs:[&per_cpu_xxxx - __per_cpu_start]
> 
>   * The boot_pdas are only needed in head64.c so move the declaration
>     over there.  And since the boot_cpu_pda is only used during
>     bootup and then copied to the per_cpu areas during init, it is
>     then removable.  In addition, the initial cpu_pda pointer table
>     is reallocated to be the correct size for the number of cpus.
> 
>   * Remove the code that allocates special pda data structures.
>     Since the percpu area is currently maintained for all possible
>     cpus then the pda regions will stay intact in case cpus are
>     hotplugged off and then back on.
> 
>   * Relocate the x86_64 percpu variables to begin at zero. Then
>     we can directly use the x86_32 percpu operations. x86_32
>     offsets %fs by __per_cpu_start. x86_64 has %gs pointing
>     directly to the pda and the per cpu area thereby allowing
>     access to the pda with the x86_64 pda operations and access
>     to the per cpu variables using x86_32 percpu operations.
> 
>   * This also supports further integration of x86_32/64.
> 
> Cc:	Andy Whitcroft <apw@shadowen.org>
> Cc:	Randy Dunlap <rdunlap@xenotime.net>
> Cc:	Joel Schopp <jschopp@austin.ibm.com>
> Signed-off-by: Christoph Lameter <clameter@sgi.com>
> Signed-off-by: Mike Travis <travis@sgi.com>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  arch/x86/Kconfig                 |    3 +
>  arch/x86/kernel/head64.c         |   41 ++++++++++++++++++++++++
>  arch/x86/kernel/setup64.c        |   66 ++++++++++++++++++++++++---------------
>  arch/x86/kernel/smpboot_64.c     |   16 ---------
>  arch/x86/kernel/vmlinux_64.lds.S |    1 
>  include/asm-x86/pda.h            |   13 +++++--
>  include/asm-x86/percpu.h         |   33 +++++++++++--------
>  7 files changed, 115 insertions(+), 58 deletions(-)
> 
> Index: linux-x86.q/arch/x86/Kconfig
> ===================================================================
> --- linux-x86.q.orig/arch/x86/Kconfig
> +++ linux-x86.q/arch/x86/Kconfig
> @@ -122,6 +122,9 @@ config ARCH_HAS_CPU_RELAX
>  config HAVE_SETUP_PER_CPU_AREA
>  	def_bool X86_64
>  
> +config HAVE_ZERO_BASED_PER_CPU
> +	def_bool X86_64
> +
>  config ARCH_HIBERNATION_POSSIBLE
>  	def_bool y
>  	depends on !SMP || !X86_VOYAGER
> Index: linux-x86.q/arch/x86/kernel/head64.c
> ===================================================================
> --- linux-x86.q.orig/arch/x86/kernel/head64.c
> +++ linux-x86.q/arch/x86/kernel/head64.c
> @@ -11,6 +11,7 @@
>  #include <linux/string.h>
>  #include <linux/percpu.h>
>  #include <linux/start_kernel.h>
> +#include <linux/bootmem.h>
>  
>  #include <asm/processor.h>
>  #include <asm/proto.h>
> @@ -23,6 +24,12 @@
>  #include <asm/kdebug.h>
>  #include <asm/e820.h>
>  
> +#ifdef CONFIG_SMP
> +/* Only used before the per cpu areas are setup. */
> +static struct x8664_pda boot_cpu_pda[NR_CPUS] __initdata;
> +static struct x8664_pda *_cpu_pda_init[NR_CPUS] __initdata;
> +#endif
> +
>  static void __init zap_identity_mappings(void)
>  {
>  	pgd_t *pgd = pgd_offset_k(0UL);
> @@ -102,8 +109,14 @@ void __init x86_64_start_kernel(char * r
>  
>  	early_printk("Kernel alive\n");
>  
> +#ifdef CONFIG_SMP
> +	_cpu_pda = (void *)_cpu_pda_init;
>   	for (i = 0; i < NR_CPUS; i++)
>   		cpu_pda(i) = &boot_cpu_pda[i];
> +#endif
> +
> +	/* setup percpu segment offset for cpu 0 */
> +	cpu_pda(0)->data_offset = (unsigned long)__per_cpu_load;
>  
>  	pda_init(0);
>  	copy_bootdata(__va(real_mode_data));
> @@ -128,3 +141,31 @@ void __init x86_64_start_kernel(char * r
>  
>  	start_kernel();
>  }
> +
> +#ifdef	CONFIG_SMP
> +/*
> + * Remove initial boot_cpu_pda array and cpu_pda pointer table.
> + *
> + * This depends on setup_per_cpu_areas relocating the pda to the beginning
> + * of the per_cpu area so that (_cpu_pda[i] != &boot_cpu_pda[i]).  If it
> + * is equal then the new pda has not been setup for this cpu, and the pda
> + * table will have a NULL address for this cpu.
> + */
> +void __init x86_64_cleanup_pda(void)
> +{
> +	int i;
> +
> +	_cpu_pda = alloc_bootmem_low(nr_cpu_ids * sizeof(void *));

Here we allocate an array of [nr_cpu_ids] slots

> +
> +	if (!_cpu_pda)
> +		panic("Cannot allocate cpu pda table\n");
> +
> +	/* cpu_pda() now points to allocated cpu_pda_table */
> +
> +	for (i = 0; i < NR_CPUS; i++)

But in this loop we want to read/write on [NR_CPUS] slots of this array

> +		if (_cpu_pda_init[i] == &boot_cpu_pda[i])
> +			cpu_pda(i) = NULL;
> +		else
> +			cpu_pda(i) = _cpu_pda_init[i];
> +}
> +#endif

You might want to apply this patch.

I also wonder if _cpu_pda should be set only at the very end of 
x86_64_cleanup_pda(), after array initialization, or maybe other
cpus are not yet running ? (Sorry I cannot boot test this patch at this momeent)

[PATCH] x86_64: x86_64_cleanup_pda() should use nr_cpu_ids instead of NR_CPUS

We allocate an array of nr_cpu_ids pointers, so we should respect its bonds.

Delay change of _cpu_pda after array initialization.

Also take into account that alloc_bootmem_low() :
- calls panic() if not enough memory
- already clears allocated memory

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>

diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 3942e6a..21532eb 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -154,18 +154,16 @@ void __init x86_64_start_kernel(char * real_mode_data)
 void __init x86_64_cleanup_pda(void)
 {
 	int i;
+	struct x8664_pda **new_cpu_pda;
 
-	_cpu_pda = alloc_bootmem_low(nr_cpu_ids * sizeof(void *));
+	new_cpu_pda = alloc_bootmem_low(nr_cpu_ids * sizeof(void *));
 
-	if (!_cpu_pda)
-		panic("Cannot allocate cpu pda table\n");
 
+	for (i = 0; i < nr_cpu_ids; i++)
+		if (_cpu_pda_init[i] != &boot_cpu_pda[i])
+			new_cpu_pda[i] = _cpu_pda_init[i];
+	mb();
+	_cpu_pda = new_cpu_pda;
 	/* cpu_pda() now points to allocated cpu_pda_table */
-
-	for (i = 0; i < NR_CPUS; i++)
-		if (_cpu_pda_init[i] == &boot_cpu_pda[i])
-			cpu_pda(i) = NULL;
-		else
-			cpu_pda(i) = _cpu_pda_init[i];
 }
 #endif

  reply	other threads:[~2008-02-20 13:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-19 20:33 [PATCH 0/2] x86: Optimize percpu accesses v3 Mike Travis
2008-02-19 20:33 ` [PATCH 1/2] x86_64: Fold pda into per cpu area v3 Mike Travis
2008-02-20 12:07   ` Ingo Molnar
2008-02-20 13:16     ` Eric Dumazet [this message]
2008-02-20 15:54       ` Mike Travis
2008-02-20 18:57     ` Mike Travis
2008-02-19 20:33 ` [PATCH 2/2] x86_64: Cleanup non-smp usage of cpu maps v3 Mike Travis
2008-03-04  1:02   ` Andrew Morton
2008-03-04  1:30     ` Andrew Morton
2008-03-04  8:35       ` Ingo Molnar
2008-03-05  0:45         ` Andrew Morton
2008-03-04 13:21     ` Mike Travis
2008-02-20  9:15 ` [PATCH 0/2] x86: Optimize percpu accesses v3 Ingo Molnar
2008-02-20 15:28   ` Mike Travis

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=20080220141659.45ec31fa.dada1@cosmosbay.com \
    --to=dada1@cosmosbay.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=apw@shadowen.org \
    --cc=clameter@sgi.com \
    --cc=jschopp@austin.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=rdunlap@xenotime.net \
    --cc=steiner@sgi.com \
    --cc=tglx@linutronix.de \
    --cc=travis@sgi.com \
    --subject='Re: [PATCH 1/2] x86_64: Fold pda into per cpu area v3' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).