From: "Martin J. Bligh" <mbligh@aracnet.com>
To: IWAMOTO Toshihiro <iwamoto@valinux.co.jp>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: memory hotremove prototype, take 3
Date: Thu, 04 Dec 2003 09:12:27 -0800 [thread overview]
Message-ID: <2840000.1070557947@flay> (raw)
In-Reply-To: <20031204154406.7FC587007A@sv1.valinux.co.jp>
>> > My target is somewhat NUMA-ish and fairly large. So I'm not sure if
>> > CONFIG_NONLINEAR fits, but CONFIG_NUMA isn't perfect either.
>>
>> If your target is NUMA, then you really, really need CONFIG_NONLINEAR.
>> We don't support multiple pgdats per node, nor do I wish to, as it'll
>> make an unholy mess ;-). With CONFIG_NONLINEAR, the discontiguities
>> within a node are buried down further, so we have much less complexity
>> to deal with from the main VM. The abstraction also keeps the poor
>> VM engineers trying to read / write the code saner via simplicity ;-)
>
> IIRC, memory is contiguous within a NUMA node. I think Goto-san will
> clarify this issue when his code gets ready. :-)
Right - but then you can't use discontigmem's multiple pgdat's inside
a node to implement hotplug mem for NUMA systems.
> Preallocating struct page array isn't feasible for the target system
> because max memory / min memory ratio is large.
> Our plan is to use the beginning (or the end) of the memory block being
> hotplugged. If a 2GB memory block is added, first ~20MB is used for
> the struct page array for the rest of the memory block.
Right - that makes perfect sense, it just has 2 problems:
1) You end up with a discontiguous mem_map array (fixable by adding a layer
of indirection in the wrapped macros).
2) on 32 bit, it's going to make a mess, as you need to map mem_map
inside the permanently mapped kernel area (aka ZONE_NORMAL+vmalloc space
except in a kind of wierd cornercase I created with remap_numa_kva,
which creates a no-man's land of permanently mapped kernel memory
between ZONE_NORMAL and VMALLOC_RESERVE area for the remapped
lmem_maps from the other nodes).
>> You could just lock the pages, I'd think? I don't see at a glance
>> exactly what you were using this for, but would that work?
>
> I haven't seriously considered to implement vmalloc'd memory, but I
> guess that would be too complicated if not impossible.
> Making kernel threads or interrupt handlers block on memory access
> sound very difficult to me.
Aahh, maybe I understand now. You're saying you don't support hotplugging
ZONE_NORMAL, so you want to restrict vmalloc accesses to the non-hotplugged
areas? In which case things like HIGHPTE will be a nightmare as well ... ;-)
You also need to be very wary of where memlocked pages are allocated from.
M.
WARNING: multiple messages have this Message-ID (diff)
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: IWAMOTO Toshihiro <iwamoto@valinux.co.jp>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: memory hotremove prototype, take 3
Date: Thu, 04 Dec 2003 09:12:27 -0800 [thread overview]
Message-ID: <2840000.1070557947@flay> (raw)
In-Reply-To: <20031204154406.7FC587007A@sv1.valinux.co.jp>
>> > My target is somewhat NUMA-ish and fairly large. So I'm not sure if
>> > CONFIG_NONLINEAR fits, but CONFIG_NUMA isn't perfect either.
>>
>> If your target is NUMA, then you really, really need CONFIG_NONLINEAR.
>> We don't support multiple pgdats per node, nor do I wish to, as it'll
>> make an unholy mess ;-). With CONFIG_NONLINEAR, the discontiguities
>> within a node are buried down further, so we have much less complexity
>> to deal with from the main VM. The abstraction also keeps the poor
>> VM engineers trying to read / write the code saner via simplicity ;-)
>
> IIRC, memory is contiguous within a NUMA node. I think Goto-san will
> clarify this issue when his code gets ready. :-)
Right - but then you can't use discontigmem's multiple pgdat's inside
a node to implement hotplug mem for NUMA systems.
> Preallocating struct page array isn't feasible for the target system
> because max memory / min memory ratio is large.
> Our plan is to use the beginning (or the end) of the memory block being
> hotplugged. If a 2GB memory block is added, first ~20MB is used for
> the struct page array for the rest of the memory block.
Right - that makes perfect sense, it just has 2 problems:
1) You end up with a discontiguous mem_map array (fixable by adding a layer
of indirection in the wrapped macros).
2) on 32 bit, it's going to make a mess, as you need to map mem_map
inside the permanently mapped kernel area (aka ZONE_NORMAL+vmalloc space
except in a kind of wierd cornercase I created with remap_numa_kva,
which creates a no-man's land of permanently mapped kernel memory
between ZONE_NORMAL and VMALLOC_RESERVE area for the remapped
lmem_maps from the other nodes).
>> You could just lock the pages, I'd think? I don't see at a glance
>> exactly what you were using this for, but would that work?
>
> I haven't seriously considered to implement vmalloc'd memory, but I
> guess that would be too complicated if not impossible.
> Making kernel threads or interrupt handlers block on memory access
> sound very difficult to me.
Aahh, maybe I understand now. You're saying you don't support hotplugging
ZONE_NORMAL, so you want to restrict vmalloc accesses to the non-hotplugged
areas? In which case things like HIGHPTE will be a nightmare as well ... ;-)
You also need to be very wary of where memlocked pages are allocated from.
M.
--
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:[~2003-12-04 17:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-01 3:41 memory hotremove prototype, take 3 IWAMOTO Toshihiro
2003-12-01 3:41 ` IWAMOTO Toshihiro
2003-12-01 19:56 ` Pavel Machek
2003-12-01 19:56 ` Pavel Machek
2003-12-03 19:41 ` Martin J. Bligh
2003-12-03 19:41 ` Martin J. Bligh
2003-12-04 3:58 ` IWAMOTO Toshihiro
2003-12-04 3:58 ` IWAMOTO Toshihiro
2003-12-04 5:38 ` Martin J. Bligh
2003-12-04 5:38 ` Martin J. Bligh
2003-12-04 15:44 ` IWAMOTO Toshihiro
2003-12-04 15:44 ` IWAMOTO Toshihiro
2003-12-04 17:12 ` Martin J. Bligh [this message]
2003-12-04 17:12 ` Martin J. Bligh
2003-12-04 18:27 ` Jesse Barnes
2003-12-04 18:27 ` Jesse Barnes
2003-12-04 18:29 ` Martin J. Bligh
2003-12-04 18:29 ` Martin J. Bligh
2003-12-04 18:59 ` Jesse Barnes
2003-12-04 18:59 ` Jesse Barnes
-- strict thread matches above, loose matches on Subject: below --
2003-12-01 20:12 Luck, Tony
2003-12-02 3:01 ` IWAMOTO Toshihiro
2003-12-02 6:43 ` Hirokazu Takahashi
2003-12-02 22:26 ` Yasunori Goto
2003-12-03 5:19 Perez-Gonzalez, Inaky
2003-12-03 17:57 Luck, Tony
2003-12-10 0:45 Luck, Tony
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=2840000.1070557947@flay \
--to=mbligh@aracnet.com \
--cc=iwamoto@valinux.co.jp \
--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.