lkml.org 
[lkml]   [2004]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 0/3] memory hotplug prototype
> I'm not trying to make my patches IA64 specific, and my patch is quite
> machine independent. However, some of them, such as placing mem_map at
> boot time or hotplug events, are machine dependent by nature.

Sounds good - maybe I'd misread your intentions - sorry.

> I'm afraid that the memsection thing is overkill for systems whose
> hotpluggable memory unit is large. I understand there's need for
> memsection, but I think that should be optional.

If you're doing things that are logically nodes on the system anyway,
that makes sense. However, I really hate the idea of breaking up existing
logical groupings of memory just to do hotplug ... zones represent a logical
type of memory to the system, where the memory is somehow logically
"different" from that in other zones (eg it fullils some restraint of
DMA or "permanently mapped kernel space", or has a different locality
to cpus (NUMA)). Yes, I know the current non-NUMA discontigmem violates
that premise (and thus must die ;-)).

Perhaps I'm confusing your patches with sombody elses - it gets hard
to keep track of all the groups involved, sorry ;-)

> BTW, I think memory hotplugging on 32 bit archs are difficult because
> of their narrow address space. For example:
> 1. A system boots with 1GB * 4 blocks of RAM.
> 2. The second RAM block is removed.
> 3. A 2GB block is inserted in the second slot.
> Where does these RAM block appear in physical space,

I don't think we have control over that - it's a machine issue.

> and where should their mem_map be placed?

ia32 has a really hard time doing that, as it has to be in permanent
KVA space. Moreover, you have alignment requirements between sections.
Probably for the first cut, we'll have to just reserve enough mem_map
for any physical address that might appear for that machine. If Dave's
nonlinear stuff can sort out the alignment requirements, we can probably
do a "vmalloc-like" remapping out of physical ranges in the new mem
segment, much as I did in remap_numa_kva for NUMA support.

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:1.895 / U:0.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site