From: Andi Kleen <andi@firstfloor.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Rik van Riel <riel@redhat.com>,
clameter@sgi.com, linux-kernel@vger.kernel.org,
lee.schermerhorn@hp.com, kosaki.motohiro@jp.fujitsu.com,
linux-mm@kvack.org, eric.whitney@hp.com,
Paul Mundt <lethal@linux-sh.org>, Ingo Molnar <mingo@elte.hu>,
Andy Whitcroft <apw@shadowen.org>
Subject: Re: [PATCH -mm 13/25] Noreclaim LRU Infrastructure
Date: Tue, 10 Jun 2008 23:48:34 +0200 [thread overview]
Message-ID: <484EF6B2.8010508@firstfloor.org> (raw)
In-Reply-To: <20080610143334.c53d7d8a.akpm@linux-foundation.org>
>
> Maybe it's time to bite the bullet and kill i386 NUMA support. afaik
> it's just NUMAQ and a 2-node NUMAish machine which IBM made (as400?)
Actually much more (most 64bit NUMA systems can run 32bit too), it just
doesn't work well because the code is not very good, undertested, many
bugs, weird design and in general 32bit NUMA has a lot of limitations
that don't make it a good idea.
But you don't need to kill it only for this (although imho there are
lots of other good reasons) Just use a different way to look up the
node. Encoding it into the flags is just an optimization.
But a separate hash or similar would also work. It seemed like a good
idea back then.
In fact there's already a hash for this (the pa->node hash) that
can do it. It' just some more instructions and one cache line
more accessed, but since i386 NUMA is a fringe application
that doesn't seem like a big issue.
-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:[~2008-06-10 21:48 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080606202838.390050172@redhat.com>
2008-06-06 20:28 ` [PATCH -mm 13/25] Noreclaim LRU Infrastructure Rik van Riel, Rik van Riel
2008-06-07 1:05 ` Andrew Morton
2008-06-08 20:34 ` Rik van Riel
2008-06-08 20:57 ` Andrew Morton
2008-06-08 21:32 ` Rik van Riel
2008-06-08 21:43 ` Ray Lee
2008-06-08 23:22 ` Andrew Morton
2008-06-08 23:34 ` Rik van Riel
2008-06-08 23:54 ` Andrew Morton
2008-06-09 0:56 ` Rik van Riel
2008-06-09 6:10 ` Andrew Morton
2008-06-09 13:44 ` Rik van Riel
2008-06-09 2:58 ` Rik van Riel
2008-06-09 5:44 ` Andrew Morton
2008-06-10 19:17 ` Christoph Lameter
2008-06-10 19:37 ` Rik van Riel
2008-06-10 21:33 ` Andrew Morton
2008-06-10 21:48 ` Andi Kleen [this message]
2008-06-10 22:05 ` Dave Hansen
2008-06-11 5:09 ` Paul Mundt
2008-06-11 6:16 ` Andrew Morton
2008-06-11 6:29 ` Paul Mundt
2008-06-11 12:06 ` Andi Kleen
2008-06-11 14:09 ` Removing node flags from page->flags was Re: [PATCH -mm 13/25] Noreclaim LRU Infrastructure II Andi Kleen
2008-06-11 19:03 ` [PATCH -mm 13/25] Noreclaim LRU Infrastructure Andy Whitcroft
2008-06-11 20:52 ` Andi Kleen
2008-06-11 23:25 ` Christoph Lameter
2008-06-08 22:03 ` Rik van Riel
2008-06-08 21:07 ` KOSAKI Motohiro
2008-06-10 20:09 ` Rik van Riel
2008-06-06 20:28 ` [PATCH -mm 15/25] Ramfs and Ram Disk pages are non-reclaimable Rik van Riel, Rik van Riel
2008-06-07 1:05 ` Andrew Morton
2008-06-08 4:32 ` Greg KH
2008-06-06 20:28 ` [PATCH -mm 17/25] Mlocked Pages " Rik van Riel, Rik van Riel
2008-06-07 1:07 ` Andrew Morton
2008-06-07 5:38 ` KOSAKI Motohiro
2008-06-10 3:31 ` Nick Piggin
2008-06-10 12:50 ` Rik van Riel
2008-06-10 21:14 ` Rik van Riel
2008-06-10 21:43 ` Lee Schermerhorn
2008-06-10 21:57 ` Andrew Morton
2008-06-11 16:01 ` Lee Schermerhorn
2008-06-10 23:48 ` Rik van Riel
2008-06-11 15:29 ` Lee Schermerhorn
2008-06-11 1:00 ` Rik van Riel
2008-06-06 20:28 ` [PATCH -mm 19/25] Handle mlocked pages during map, remap, unmap Rik van Riel, Rik van Riel
2008-06-06 20:28 ` [PATCH -mm 21/25] Cull non-reclaimable pages in fault path Rik van Riel, Rik van Riel, Lee Schermerhorn
2008-06-06 20:29 ` [PATCH -mm 23/25] Noreclaim LRU scan sysctl Rik van Riel, Rik van Riel, Lee Schermerhorn
2008-06-06 20:29 ` [PATCH -mm 25/25] Noreclaim LRU and Mlocked Pages Documentation Rik van Riel, Rik van Riel
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=484EF6B2.8010508@firstfloor.org \
--to=andi@firstfloor.org \
--cc=akpm@linux-foundation.org \
--cc=apw@shadowen.org \
--cc=clameter@sgi.com \
--cc=eric.whitney@hp.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=lee.schermerhorn@hp.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=riel@redhat.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