Re: [PATCH: 002/017]Memory hotplug for new nodes v.4.(change name old add_memory() to arch_add_memory())

On Wed, 2006-03-22 at 09:05 +0900, KAMEZAWA Hiroyuki wrote:
> On Tue, 21 Mar 2006 10:00:12 -0800
> Dave Hansen <[email protected]> wrote:
> > At some point in the process, you need to export the NUMA node layout to
> > the rest of the system, to say which pages go in which node.  I'm just
> > saying that you should do that _before_ add_memory().
> > 
> To do so, we have to maintain new pfn_to_nid() function.
> We have to maintain a new table/list and have to consider name of it :).

I completely spaced out, and forgot that we use sparsemem and 'struct
pages' for pfn_to_nid() now.  I've been buried too deep in the i386
discontigmem physnode_map[].  Sorry.

If I missed it before, please refresh my memory.  But, if we're
providing arch_nid_probe(addr), then why don't we just call it inside of
add_memory() on the start address, instead of in the generic code?

I'm also getting a bit confused in your patches whether add_memory() is
the _original_ add_memory(), or the new one.  It tends to get lost in 17
patches. :(

I don't really like the arch_nid_probe() name.  We need to make it very
apparent that it is to be used _only_ for memory hotplug operations.  It
has no meaning for anything else.

	hotplug_physaddr_to_nid()?

Maybe with a "memory_" in front.  Maybe even
memory_add_physaddr_to_nid()?

It was probably to keep from changing as little code as possible, but
please convert the u64 values to pfns as soon as possible.  I noticed
that hotadd_new_pgdat() still deals with them, and does the shift as
well.  Is that really necessary.

The u64s should not be kept for more than one level of calls.  That
level of calls should be the firmware.  So, let the firmware call into
the VM code with u64s, then have all of the plain VM code deal in pfns.

-- Dave

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

---

• Follow-Ups:
  • Re: [PATCH: 002/017]Memory hotplug for new nodes v.4.(change name old add_memory() to arch_add_memory())
    • From: KAMEZAWA Hiroyuki <[email protected]>

• References:
  • [PATCH: 002/017]Memory hotplug for new nodes v.4.(change name old add_memory() to arch_add_memory())
    • From: Yasunori Goto <[email protected]>
  • Re: [PATCH: 002/017]Memory hotplug for new nodes v.4.(change name old add_memory() to arch_add_memory())
    • From: Dave Hansen <[email protected]>
  • Re: [PATCH: 002/017]Memory hotplug for new nodes v.4.(change name old add_memory() to arch_add_memory())
    • From: KAMEZAWA Hiroyuki <[email protected]>
  • Re: [PATCH: 002/017]Memory hotplug for new nodes v.4.(change name old add_memory() to arch_add_memory())
    • From: Dave Hansen <[email protected]>
  • Re: [PATCH: 002/017]Memory hotplug for new nodes v.4.(change name old add_memory() to arch_add_memory())
    • From: KAMEZAWA Hiroyuki <[email protected]>

• Prev by Date: Re: [PATCH] Add SA_PERCPU_IRQ flag support
• Next by Date: Re: [PATCH] fix memory leak in mm/slab.c::alloc_kmemlist() (try #3)
• Previous by thread: Re: [PATCH: 002/017]Memory hotplug for new nodes v.4.(change name old add_memory() to arch_add_memory())
• Next by thread: Re: [PATCH: 002/017]Memory hotplug for new nodes v.4.(change name old add_memory() to arch_add_memory())
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]