All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Daniel J Blueman <daniel@numascale.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, Steffen Persvold <sp@numascale.com>
Subject: Re: [PATCH v2 5/5] Numachip: use 2GB memory block size
Date: Sun, 19 Oct 2014 11:23:25 +0200	[thread overview]
Message-ID: <20141019092324.GA10027@gmail.com> (raw)
In-Reply-To: <1413683152-31302-5-git-send-email-daniel@numascale.com>


* Daniel J Blueman <daniel@numascale.com> wrote:

> Use appropriate memory block size to reduce sysfs entry creation time
> by 16x.
> 
> Boot-tested with the four permutations of X86_UV and X86_NUMACHIP.
> 
> Signed-off-by: Daniel J Blueman <daniel@numascale.com>
> ---
>  arch/x86/mm/init_64.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 5621c47..22ea6de 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -53,6 +53,7 @@
>  #include <asm/cacheflush.h>
>  #include <asm/init.h>
>  #include <asm/uv/uv.h>
> +#include <asm/numachip/numachip.h>
>  #include <asm/setup.h>
>  
>  #include "mm_internal.h"
> @@ -1235,9 +1236,9 @@ static unsigned long probe_memory_block_size(void)
>  	/* start from 2g */
>  	unsigned long bz = 1UL<<31;
>  
> -#ifdef CONFIG_X86_UV
> -	if (is_uv_system()) {
> -		printk(KERN_INFO "UV: memory block size 2GB\n");
> +#ifdef CONFIG_X86_64
> +	if (is_uv_system() || is_numachip_system()) {
> +		pr_info("Memory block size 2GB for large-SMP system\n");
>  		return 2UL * 1024 * 1024 * 1024;

It would be a lot cleaner and more robust to have a more 
intelligent decision here.

Is there a reliable indicator for large 'sysfs entry creation 
time', such as a lot of RAM present?

Also, it would be nice to list the pros/cons of this change, an 
advantage is reduced overhead - what are the disadvantages?

Thanks,

	Ingo

  reply	other threads:[~2014-10-19  9:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-19  1:45 [PATCH v2 1/5] Numachip: Fix build failure with trunk GCC Daniel J Blueman
2014-10-19  1:45 ` [PATCH v2 2/5] Numachip: APIC fixes Daniel J Blueman
2014-10-19  9:24   ` Ingo Molnar
2014-10-19  1:45 ` [PATCH v2 3/5] Numachip: Add safe is-present function Daniel J Blueman
2014-10-19  1:45 ` [PATCH v2 4/5] Numachip: APIC driver cleanups Daniel J Blueman
2014-10-19  1:45 ` [PATCH v2 5/5] Numachip: use 2GB memory block size Daniel J Blueman
2014-10-19  9:23   ` Ingo Molnar [this message]
2014-10-20  7:03     ` Daniel J Blueman
2014-10-20 12:02       ` Ingo Molnar

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=20141019092324.GA10027@gmail.com \
    --to=mingo@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=daniel@numascale.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=sp@numascale.com \
    --cc=tglx@linutronix.de \
    --cc=x86@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.