All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-ia64@vger.kernel.org
Subject: Re: [RFC][PATCH 3/9] actual generic PAGE_SIZE infrastructure
Date: Thu, 31 Aug 2006 17:57:38 +0000	[thread overview]
Message-ID: <1157047058.31295.28.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0608301658130.5789@schroedinger.engr.sgi.com>

On Wed, 2006-08-30 at 17:08 -0700, Christoph Lameter wrote:
> On Wed, 30 Aug 2006, Dave Hansen wrote:
> 
> >  #endif	/* CONFIG_ARCH_HAVE_GET_ORDER */
> > -#endif /*  __ASSEMBLY__ */
> > +#endif  /* __ASSEMBLY__ */
>          ^^^ Extra blank.

OK.  I'll fix that.

> > +	prompt "Kernel Page Size"
> 	               page size?

Sure.

> > +	  This lets you select the page size of the kernel.  For best
> > +	  32-bit compatibility on 64-bit architectures, a page size of 4KB
> > +	  should be selected (although most binaries work perfectly fine with
> > +	  a larger page size).  For best performance, a page size of larger
> > +	  than 4KB is recommended.  However, there are a number of
> > +	  side-effects of larger page sizes, like small files fitting poorly
> > +	  into the page cache.
> 
> Could we change this somewhat? Avoid the direct address and maybe say:
> 
>  The kernel page size determines the basic chunk of memory handled
>  by the Linux VM. The bigger the page size the less page objects
>  have to be managed by the kernel which reduces the VM overhead in
>  handling large amounts of data. However, larger pages also lead
>  to memory being wasted by the kernel since small files will
>  at mininum require one page of memory. A 4K pagesize is fairly standard 
>  and may be required for 32 bit compatibility on many platforms.
> 
>  It is usually not wise to select another page size than the default
>  unless one knows what one is doing or has some time to spend on
>  getting to know the kernel.

This is very nice.  I'll incorporate it.  

> Note that the default pagesize on IA64 is 16K and some important things 
> would change if a lesser size is selected. I have never run a 4K kernel. 
> I do not think we can just say that 4KB is okay. There may be other 
> platforms that have other default page sizes.

If we can't just say that it is OK, then we should probably disable it
in Kconfig.  Should we do that?

-- Dave


WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <haveblue@us.ibm.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-ia64@vger.kernel.org
Subject: Re: [RFC][PATCH 3/9] actual generic PAGE_SIZE infrastructure
Date: Thu, 31 Aug 2006 10:57:38 -0700	[thread overview]
Message-ID: <1157047058.31295.28.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0608301658130.5789@schroedinger.engr.sgi.com>

On Wed, 2006-08-30 at 17:08 -0700, Christoph Lameter wrote:
> On Wed, 30 Aug 2006, Dave Hansen wrote:
> 
> >  #endif	/* CONFIG_ARCH_HAVE_GET_ORDER */
> > -#endif /*  __ASSEMBLY__ */
> > +#endif  /* __ASSEMBLY__ */
>          ^^^ Extra blank.

OK.  I'll fix that.

> > +	prompt "Kernel Page Size"
> 	               page size?

Sure.

> > +	  This lets you select the page size of the kernel.  For best
> > +	  32-bit compatibility on 64-bit architectures, a page size of 4KB
> > +	  should be selected (although most binaries work perfectly fine with
> > +	  a larger page size).  For best performance, a page size of larger
> > +	  than 4KB is recommended.  However, there are a number of
> > +	  side-effects of larger page sizes, like small files fitting poorly
> > +	  into the page cache.
> 
> Could we change this somewhat? Avoid the direct address and maybe say:
> 
>  The kernel page size determines the basic chunk of memory handled
>  by the Linux VM. The bigger the page size the less page objects
>  have to be managed by the kernel which reduces the VM overhead in
>  handling large amounts of data. However, larger pages also lead
>  to memory being wasted by the kernel since small files will
>  at mininum require one page of memory. A 4K pagesize is fairly standard 
>  and may be required for 32 bit compatibility on many platforms.
> 
>  It is usually not wise to select another page size than the default
>  unless one knows what one is doing or has some time to spend on
>  getting to know the kernel.

This is very nice.  I'll incorporate it.  

> Note that the default pagesize on IA64 is 16K and some important things 
> would change if a lesser size is selected. I have never run a 4K kernel. 
> I do not think we can just say that 4KB is okay. There may be other 
> platforms that have other default page sizes.

If we can't just say that it is OK, then we should probably disable it
in Kconfig.  Should we do that?

-- Dave


WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <haveblue@us.ibm.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-ia64@vger.kernel.org
Subject: Re: [RFC][PATCH 3/9] actual generic PAGE_SIZE infrastructure
Date: Thu, 31 Aug 2006 10:57:38 -0700	[thread overview]
Message-ID: <1157047058.31295.28.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0608301658130.5789@schroedinger.engr.sgi.com>

On Wed, 2006-08-30 at 17:08 -0700, Christoph Lameter wrote:
> On Wed, 30 Aug 2006, Dave Hansen wrote:
> 
> >  #endif	/* CONFIG_ARCH_HAVE_GET_ORDER */
> > -#endif /*  __ASSEMBLY__ */
> > +#endif  /* __ASSEMBLY__ */
>          ^^^ Extra blank.

OK.  I'll fix that.

> > +	prompt "Kernel Page Size"
> 	               page size?

Sure.

> > +	  This lets you select the page size of the kernel.  For best
> > +	  32-bit compatibility on 64-bit architectures, a page size of 4KB
> > +	  should be selected (although most binaries work perfectly fine with
> > +	  a larger page size).  For best performance, a page size of larger
> > +	  than 4KB is recommended.  However, there are a number of
> > +	  side-effects of larger page sizes, like small files fitting poorly
> > +	  into the page cache.
> 
> Could we change this somewhat? Avoid the direct address and maybe say:
> 
>  The kernel page size determines the basic chunk of memory handled
>  by the Linux VM. The bigger the page size the less page objects
>  have to be managed by the kernel which reduces the VM overhead in
>  handling large amounts of data. However, larger pages also lead
>  to memory being wasted by the kernel since small files will
>  at mininum require one page of memory. A 4K pagesize is fairly standard 
>  and may be required for 32 bit compatibility on many platforms.
> 
>  It is usually not wise to select another page size than the default
>  unless one knows what one is doing or has some time to spend on
>  getting to know the kernel.

This is very nice.  I'll incorporate it.  

> Note that the default pagesize on IA64 is 16K and some important things 
> would change if a lesser size is selected. I have never run a 4K kernel. 
> I do not think we can just say that 4KB is okay. There may be other 
> platforms that have other default page sizes.

If we can't just say that it is OK, then we should probably disable it
in Kconfig.  Should we do that?

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2006-08-31 17:57 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-30 22:16 [RFC][PATCH 0/9] generic PAGE_SIZE infrastructure (v4) Dave Hansen
2006-08-30 22:16 ` Dave Hansen
2006-08-30 22:16 ` Dave Hansen
2006-08-30 22:16 ` [RFC][PATCH 2/9] conditionally define generic get_order() (ARCH_HAS_GET_ORDER) Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-31 18:41   ` Haavard Skinnemoen
2006-08-31 18:41     ` Haavard Skinnemoen
2006-08-31 18:41     ` Haavard Skinnemoen
2006-08-31 19:51     ` [RFC][PATCH 2/9] conditionally define generic get_order() Dave Hansen
2006-08-31 19:51       ` [RFC][PATCH 2/9] conditionally define generic get_order() (ARCH_HAS_GET_ORDER) Dave Hansen
2006-08-31 19:51       ` Dave Hansen
2006-08-30 22:16 ` [RFC][PATCH 1/9] put alignment macros in align.h Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-30 22:16 ` [RFC][PATCH 3/9] actual generic PAGE_SIZE infrastructure Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-31  0:08   ` Christoph Lameter
2006-08-31  0:08     ` Christoph Lameter
2006-08-31  0:08     ` Christoph Lameter
2006-08-31 17:57     ` Dave Hansen [this message]
2006-08-31 17:57       ` Dave Hansen
2006-08-31 17:57       ` Dave Hansen
2006-08-31 18:06       ` Christoph Lameter
2006-08-31 18:06         ` Christoph Lameter
2006-08-31 18:06         ` Christoph Lameter
2006-08-31 20:50     ` Dave Hansen
2006-08-31 20:50       ` Dave Hansen
2006-08-31 20:50       ` Dave Hansen
2006-09-05 11:20   ` Martin Waitz
2006-09-05 11:20     ` Martin Waitz
2006-09-05 16:47     ` Dave Hansen
2006-09-05 16:47       ` Dave Hansen
2006-09-05 16:47       ` Dave Hansen
2006-10-17  7:29   ` Qi Yong
2006-10-17  7:29     ` Qi Yong
2006-10-17  7:29     ` Qi Yong
2006-08-30 22:16 ` [RFC][PATCH 4/9] ia64 generic PAGE_SIZE Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-30 23:57   ` Christoph Lameter
2006-08-30 23:57     ` Christoph Lameter
2006-08-30 23:57     ` Christoph Lameter
2006-08-31 17:38     ` Dave Hansen
2006-08-31 17:38       ` Dave Hansen
2006-08-31 17:38       ` Dave Hansen
2006-08-31 17:39       ` Christoph Lameter
2006-08-31 17:39         ` Christoph Lameter
2006-08-31 17:39         ` Christoph Lameter
2006-08-30 22:16 ` [RFC][PATCH 5/9] sparc64 " Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-30 22:27   ` David Miller
2006-08-30 22:27     ` David Miller, Dave Hansen
2006-08-30 22:27     ` David Miller
2006-08-30 22:16 ` [RFC][PATCH 6/9] mips " Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-30 22:16 ` [RFC][PATCH 7/9] parisc " Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-30 22:40   ` Kyle McMartin
2006-08-30 22:40     ` Kyle McMartin
2006-08-30 22:40     ` Kyle McMartin
2006-08-30 22:48     ` Dave Hansen
2006-08-30 22:48       ` Dave Hansen
2006-08-30 22:48       ` Dave Hansen
2006-08-30 22:16 ` [RFC][PATCH 8/9] powerpc " Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-30 22:16 ` [RFC][PATCH 9/9] convert the "easy" architectures to " Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-30 22:16   ` Dave Hansen
2006-08-31  0:33 ` [RFC][PATCH 0/9] generic PAGE_SIZE infrastructure (v4) Paul Mackerras
2006-08-31  0:33   ` Paul Mackerras
2006-08-31  0:33   ` Paul Mackerras
2006-08-31 21:03   ` Dave Hansen
2006-08-31 21:03     ` Dave Hansen
2006-08-31 21:03     ` Dave Hansen

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=1157047058.31295.28.camel@localhost.localdomain \
    --to=haveblue@us.ibm.com \
    --cc=clameter@sgi.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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.