From: Andi Kleen <andi@firstfloor.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Christoph Lameter <clameter@sgi.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
David Miller <davem@davemloft.net>,
Daniel Phillips <phillips@google.com>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Matt Mackall <mpm@selenic.com>,
Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
Steve Dickson <SteveD@redhat.com>
Subject: Re: [PATCH 03/10] mm: tag reseve pages
Date: Mon, 6 Aug 2007 22:18:12 +0200 [thread overview]
Message-ID: <20070806201812.GA23635@one.firstfloor.org> (raw)
In-Reply-To: <20070806121053.baed9691.akpm@linux-foundation.org>
On Mon, Aug 06, 2007 at 12:10:53PM -0700, Andrew Morton wrote:
> On Mon, 6 Aug 2007 20:59:26 +0200 Andi Kleen <andi@firstfloor.org> wrote:
>
> > > precious page flag
> >
> > I always cringe when I hear that. It's really more than node/sparsemem
> > use too many bits. If we get rid of 32bit NUMA that problem would be
> > gone for the node at least because it could be moved into the mostly
> > unused upper 32bit part on 64bit architectures.
>
> Removing 32-bit NUMA is attractive - NUMAQ we can probably live without,
> not sure about summit. But superh is starting to use NUMA now, due to
> varying access times of various sorts of memory, and one can envisage other
> embedded setups doing that.
They can just use phys_to_nid() or equivalent instead. Putting the node
into the page flags is just a very minor optimization. I doubt
actually you could benchmark the difference. While in theory the
hash lookup could be another cache miss in practice this should
be already hot since it's used elsewhere.
> Plus I don't think there are many flags left in the upper 32-bits. ia64
> swooped in and gobbled lots of them, although it's not immediately clear
> how many were consumed.
Really? They forgot to document it then.
Anyways, if they don't have enough bits left they can always just
use the hash table and drop the node completely. Shouldn't make too much
difference and IA64 has gobs of cache anyways.
I'm actually thinking about a PG_arch_2 on x86_64 too. arch_1 is already
used now but another one would be useful in c_p_a().
-Andi
--
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>
next prev parent reply other threads:[~2007-08-06 20:18 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-06 10:29 [PATCH 00/10] foundations for reserve-based allocation Peter Zijlstra
2007-08-06 10:29 ` [PATCH 01/10] mm: gfp_to_alloc_flags() Peter Zijlstra
2007-08-06 10:29 ` [PATCH 02/10] mm: system wide ALLOC_NO_WATERMARK Peter Zijlstra
2007-08-06 18:11 ` Christoph Lameter
2007-08-06 18:21 ` Daniel Phillips
2007-08-06 18:31 ` Peter Zijlstra
2007-08-06 18:43 ` Daniel Phillips
2007-08-06 19:11 ` Christoph Lameter
2007-08-06 19:31 ` Peter Zijlstra
2007-08-06 20:12 ` Christoph Lameter
2007-08-06 18:42 ` Christoph Lameter
2007-08-06 18:48 ` Daniel Phillips
2007-08-06 18:51 ` Christoph Lameter
2007-08-06 19:15 ` Daniel Phillips
2007-08-06 20:12 ` Matt Mackall
2007-08-06 20:19 ` Christoph Lameter
2007-08-06 20:26 ` Peter Zijlstra
2007-08-06 21:05 ` Christoph Lameter
2007-08-06 22:59 ` Daniel Phillips
2007-08-06 23:14 ` Christoph Lameter
2007-08-06 23:49 ` Daniel Phillips
2007-08-07 22:18 ` Christoph Lameter
2007-08-08 7:24 ` Peter Zijlstra
2007-08-08 18:06 ` Christoph Lameter
2007-08-08 7:37 ` Daniel Phillips
2007-08-08 18:09 ` Christoph Lameter
2007-08-09 18:41 ` Daniel Phillips
2007-08-09 18:49 ` Christoph Lameter
2007-08-10 0:17 ` Daniel Phillips
2007-08-10 1:48 ` Christoph Lameter
2007-08-10 3:34 ` Daniel Phillips
2007-08-10 3:48 ` Christoph Lameter
2007-08-10 8:15 ` Daniel Phillips
2007-08-10 17:46 ` Christoph Lameter
2007-08-10 23:25 ` Daniel Phillips
2007-08-13 6:55 ` Daniel Phillips
2007-08-13 23:04 ` Christoph Lameter
2007-08-06 20:27 ` Andrew Morton
2007-08-06 23:16 ` Daniel Phillips
2007-08-06 22:47 ` Daniel Phillips
2007-08-06 10:29 ` [PATCH 03/10] mm: tag reseve pages Peter Zijlstra
2007-08-06 18:11 ` Christoph Lameter
2007-08-06 18:13 ` Daniel Phillips
2007-08-06 18:28 ` Peter Zijlstra
2007-08-06 19:34 ` Andi Kleen
2007-08-06 18:43 ` Christoph Lameter
2007-08-06 18:47 ` Peter Zijlstra
2007-08-06 18:59 ` Andi Kleen
2007-08-06 19:09 ` Christoph Lameter
2007-08-06 19:10 ` Andrew Morton
2007-08-06 19:16 ` Christoph Lameter
2007-08-06 19:38 ` Matt Mackall
2007-08-06 20:18 ` Andi Kleen [this message]
2007-08-06 10:29 ` [PATCH 04/10] mm: slub: add knowledge of reserve pages Peter Zijlstra
2007-08-08 0:13 ` Christoph Lameter
2007-08-08 1:44 ` Matt Mackall
2007-08-08 17:13 ` Christoph Lameter
2007-08-08 17:39 ` Andrew Morton
2007-08-08 17:57 ` Christoph Lameter
2007-08-08 18:46 ` Andrew Morton
2007-08-10 1:54 ` Daniel Phillips
2007-08-10 2:01 ` Christoph Lameter
2007-08-20 7:38 ` Peter Zijlstra
2007-08-20 7:43 ` Peter Zijlstra
2007-08-20 9:12 ` Pekka J Enberg
2007-08-20 9:17 ` Peter Zijlstra
2007-08-20 9:28 ` Pekka Enberg
2007-08-20 19:26 ` Christoph Lameter
2007-08-20 20:08 ` Peter Zijlstra
2007-08-06 10:29 ` [PATCH 05/10] mm: allow mempool to fall back to memalloc reserves Peter Zijlstra
2007-08-06 10:29 ` [PATCH 06/10] mm: kmem_estimate_pages() Peter Zijlstra
2007-08-06 10:29 ` [PATCH 07/10] mm: allow PF_MEMALLOC from softirq context Peter Zijlstra
2007-08-06 10:29 ` [PATCH 08/10] mm: serialize access to min_free_kbytes Peter Zijlstra
2007-08-06 10:29 ` [PATCH 09/10] mm: emergency pool Peter Zijlstra
2007-08-06 10:29 ` [PATCH 10/10] mm: __GFP_MEMALLOC Peter Zijlstra
2007-08-06 17:35 ` [PATCH 00/10] foundations for reserve-based allocation Daniel Phillips
2007-08-06 18:17 ` Peter Zijlstra
2007-08-06 18:40 ` Daniel Phillips
2007-08-06 19:31 ` Daniel Phillips
2007-08-06 19:36 ` Peter Zijlstra
2007-08-06 19:53 ` Daniel Phillips
2007-08-06 17:56 ` Christoph Lameter
2007-08-06 18:33 ` Peter Zijlstra
2007-08-06 20:23 ` Matt Mackall
2007-08-07 0:09 ` Daniel Phillips
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=20070806201812.GA23635@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=Lee.Schermerhorn@hp.com \
--cc=SteveD@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=penberg@cs.helsinki.fi \
--cc=phillips@google.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