From: Andy Whitcroft <apw@shadowen.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Dave Hansen <haveblue@us.ibm.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"Martin J. Bligh" <mbligh@aracnet.com>
Subject: Re: [PATCH 0/4] sparsemem intro patches
Date: Thu, 17 Mar 2005 16:21:20 +0000 [thread overview]
Message-ID: <4239AE80.1070403@shadowen.org> (raw)
In-Reply-To: <20050314183042.7e7087a2.akpm@osdl.org>
Andrew Morton wrote:
> Dave Hansen <haveblue@us.ibm.com> wrote:
>
>> The following four patches provide the last needed changes before the
>> introduction of sparsemem. For a more complete description of what this
>> will do, please see this patch:
>>
>> http://www.sr71.net/patches/2.6.11/2.6.11-bk7-mhp1/broken-out/B-sparse-150-sparsemem.patch
> I don't know what to think about this. Can you describe sparsemem a little
> further, differentiate it from discontigmem and tell us why we want one?
> Is it for memory hotplug? If so, how does it support hotplug?
SPARSEMEM was born out of discussions which followed the OLS last year
over the NONLINEAR memory model which was being proposed for hotplug.
We got interested as it appeared that a simple form of NONLINEAR memory
could help us handle some problematics cases with DISCONTIG memory.
Particularly the case where we have large intra-node memory holes.
The DISCONTIGMEM memory model appears to have been designed to handle
discontiguous UMA configuration. It was subsequently put into service
to provide node support under NUMA configurations. This dual use seems
to have led to confusing code and compromises on functionality. In its
current form we can only express inter-node memory spaces, making it
majorly inefficient for NUMA systems with sparse physical inter-node
memory maps, effectivly not supporting some configurations. Also,
although DISCONTIGMEM is a common model between a number of
architectures there is almost no code overlap.
SPARSEMEM essentially is a replacement for DISCONTIGMEM providing
support for non-contigious memory but with the advantage of handling
both inter- and intra-node memory holes. The goal of the implementation
was to design a clean memory memory model covering the needs of both UMA
and NUMA discontigouos memory layouts whilst providing a basis for
hotplug. This should allow us to consolidate the implementation of
various "discontiguous" memory model whilst trying to fix its short comings.
Hotplug at its most complex puts two requirements on the memory model.
Firstly, It requires the arbirary replacement of physical memory with
memory which may be at a different address (the breaking of V=P+c) to
cope with the case of memory replacement under unmovable kernel objects.
Secondly, it requires we cope with memory "all over" the physical map.
SPARSEMEM is geared towards providing the required infrastructure for
NONLINEAR memory needed in hotplug. The idea being that NONLINEAR would
be layered on top of it and share its implementation.
-apw.
--
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:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2005-03-17 16:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-14 21:14 Dave Hansen
2005-03-14 21:50 ` David S. Miller
2005-03-14 22:18 ` Dave Hansen
2005-03-14 22:33 ` David S. Miller
2005-03-15 2:30 ` Andrew Morton
2005-03-15 3:53 ` Dave Hansen
2005-03-15 14:56 ` Martin J. Bligh
2005-03-17 16:21 ` Andy Whitcroft [this message]
2005-03-19 19:33 ` Pavel Machek
2005-03-28 21:23 ` Dave Hansen
2005-03-28 22:22 ` Pavel Machek
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=4239AE80.1070403@shadowen.org \
--to=apw@shadowen.org \
--cc=akpm@osdl.org \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mbligh@aracnet.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