All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yasunori Goto <y-goto@jp.fujitsu.com>
To: Andrew Morton <akpm@osdl.org>
Cc: tony.luck@intel.com, ak@suse.de, jschopp@austin.ibm.com,
	haveblue@us.ibm.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-ia64@vger.kernel.org
Subject: Re: [PATCH: 000/017] (RFC)Memory hotplug for new nodes v.3.
Date: Fri, 10 Mar 2006 07:13:02 +0000	[thread overview]
Message-ID: <20060310145025.CA6F.Y-GOTO@jp.fujitsu.com> (raw)
In-Reply-To: <20060309040021.3cf64e4b.akpm@osdl.org>

Thank you for your comment.
I'm very glad. :-)

> Yasunori Goto <y-goto@jp.fujitsu.com> wrote:
> >
> > I'll post newest patches for memory hotadd with pgdat allocation as V3.
> >  There are many changes to make more common code.
> 
> General comments:
> 
> - Thanks for working against -mm.  It can be a bit of a pain, but it
>   eases staging and integration later on.
> 
> - Please review all the code to check that all those functions which can
>   be made static are indeed made static.  I see quite a few global
>   functions there.
> - Make sure that all functions which can be tagged __meminit are so tagged.
> 
> - It would be useful to build a CONFIG_MEMORY_HOTPLUG=n kernel both with
>   and without the patchsets and to publish and maintain the increase in
>   code size.  Ideally that increase will be zero.  Probably it won't be,
>   and it'd be nice to understand why, and to minimise it.

Ok. I'll check and fix it.

> 
> - Arch issues:
> 
>   - Which architectures is this patchset aimed at and tested on?

      IA64.
      At least, Fujitsu is making this style hot-add feature
      on ia64 box which is named as PrimeQuest.
      (SGI or HP might wait it.)

>   - Which other architectures might be able to use this code in the
>     future?  Because we should ask the maintainers of those other
>     architectures to take a look at the changes.

      I heard from Andi-san that x86-64 will need this.
      And ppc64 might use some of my patch.

      It depends on ....
         - There is Numa box on its architecture.
         - One node of NUMA will be hot-added.

> - What locking does node hot-add use?  There are quite a few places in
>   the kernel which cheerfully iterate across node lists while assuming that
>   they won't change.  The usage of stop_machine_run() is supposed to cover
>   all that, I assume?

    If my understanding is correct, there is 2 critical point.
      - One is zonelist update, indeed. Stop_machine_run() can
        cover it.
      - Another is node_online_map and NODE_DATA().
        If node_online_map is onlined before that 
        NODE_DATA() is updated, or before that pgdat is initialized,
        kernel might touch uninitialized pgdat.
        So, node_set_online() is called at final point. 
    
    The old kernel had pgdat->next link list, it was also critial point
    for hot-add. But current -mm remove it. So, it is not issue now. :-)

Thanks.

-- 
Yasunori Goto 



WARNING: multiple messages have this Message-ID (diff)
From: Yasunori Goto <y-goto@jp.fujitsu.com>
To: Andrew Morton <akpm@osdl.org>
Cc: tony.luck@intel.com, ak@suse.de, jschopp@austin.ibm.com,
	haveblue@us.ibm.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-ia64@vger.kernel.org
Subject: Re: [PATCH: 000/017] (RFC)Memory hotplug for new nodes v.3.
Date: Fri, 10 Mar 2006 16:13:02 +0900	[thread overview]
Message-ID: <20060310145025.CA6F.Y-GOTO@jp.fujitsu.com> (raw)
In-Reply-To: <20060309040021.3cf64e4b.akpm@osdl.org>

Thank you for your comment.
I'm very glad. :-)

> Yasunori Goto <y-goto@jp.fujitsu.com> wrote:
> >
> > I'll post newest patches for memory hotadd with pgdat allocation as V3.
> >  There are many changes to make more common code.
> 
> General comments:
> 
> - Thanks for working against -mm.  It can be a bit of a pain, but it
>   eases staging and integration later on.
> 
> - Please review all the code to check that all those functions which can
>   be made static are indeed made static.  I see quite a few global
>   functions there.
> - Make sure that all functions which can be tagged __meminit are so tagged.
> 
> - It would be useful to build a CONFIG_MEMORY_HOTPLUG=n kernel both with
>   and without the patchsets and to publish and maintain the increase in
>   code size.  Ideally that increase will be zero.  Probably it won't be,
>   and it'd be nice to understand why, and to minimise it.

Ok. I'll check and fix it.

> 
> - Arch issues:
> 
>   - Which architectures is this patchset aimed at and tested on?

      IA64.
      At least, Fujitsu is making this style hot-add feature
      on ia64 box which is named as PrimeQuest.
      (SGI or HP might wait it.)

>   - Which other architectures might be able to use this code in the
>     future?  Because we should ask the maintainers of those other
>     architectures to take a look at the changes.

      I heard from Andi-san that x86-64 will need this.
      And ppc64 might use some of my patch.

      It depends on ....
         - There is Numa box on its architecture.
         - One node of NUMA will be hot-added.

> - What locking does node hot-add use?  There are quite a few places in
>   the kernel which cheerfully iterate across node lists while assuming that
>   they won't change.  The usage of stop_machine_run() is supposed to cover
>   all that, I assume?

    If my understanding is correct, there is 2 critical point.
      - One is zonelist update, indeed. Stop_machine_run() can
        cover it.
      - Another is node_online_map and NODE_DATA().
        If node_online_map is onlined before that 
        NODE_DATA() is updated, or before that pgdat is initialized,
        kernel might touch uninitialized pgdat.
        So, node_set_online() is called at final point. 
    
    The old kernel had pgdat->next link list, it was also critial point
    for hot-add. But current -mm remove it. So, it is not issue now. :-)

Thanks.

-- 
Yasunori Goto 



WARNING: multiple messages have this Message-ID (diff)
From: Yasunori Goto <y-goto@jp.fujitsu.com>
To: Andrew Morton <akpm@osdl.org>
Cc: tony.luck@intel.com, ak@suse.de, jschopp@austin.ibm.com,
	haveblue@us.ibm.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-ia64@vger.kernel.org
Subject: Re: [PATCH: 000/017] (RFC)Memory hotplug for new nodes v.3.
Date: Fri, 10 Mar 2006 16:13:02 +0900	[thread overview]
Message-ID: <20060310145025.CA6F.Y-GOTO@jp.fujitsu.com> (raw)
In-Reply-To: <20060309040021.3cf64e4b.akpm@osdl.org>

Thank you for your comment.
I'm very glad. :-)

> Yasunori Goto <y-goto@jp.fujitsu.com> wrote:
> >
> > I'll post newest patches for memory hotadd with pgdat allocation as V3.
> >  There are many changes to make more common code.
> 
> General comments:
> 
> - Thanks for working against -mm.  It can be a bit of a pain, but it
>   eases staging and integration later on.
> 
> - Please review all the code to check that all those functions which can
>   be made static are indeed made static.  I see quite a few global
>   functions there.
> - Make sure that all functions which can be tagged __meminit are so tagged.
> 
> - It would be useful to build a CONFIG_MEMORY_HOTPLUG=n kernel both with
>   and without the patchsets and to publish and maintain the increase in
>   code size.  Ideally that increase will be zero.  Probably it won't be,
>   and it'd be nice to understand why, and to minimise it.

Ok. I'll check and fix it.

> 
> - Arch issues:
> 
>   - Which architectures is this patchset aimed at and tested on?

      IA64.
      At least, Fujitsu is making this style hot-add feature
      on ia64 box which is named as PrimeQuest.
      (SGI or HP might wait it.)

>   - Which other architectures might be able to use this code in the
>     future?  Because we should ask the maintainers of those other
>     architectures to take a look at the changes.

      I heard from Andi-san that x86-64 will need this.
      And ppc64 might use some of my patch.

      It depends on ....
         - There is Numa box on its architecture.
         - One node of NUMA will be hot-added.

> - What locking does node hot-add use?  There are quite a few places in
>   the kernel which cheerfully iterate across node lists while assuming that
>   they won't change.  The usage of stop_machine_run() is supposed to cover
>   all that, I assume?

    If my understanding is correct, there is 2 critical point.
      - One is zonelist update, indeed. Stop_machine_run() can
        cover it.
      - Another is node_online_map and NODE_DATA().
        If node_online_map is onlined before that 
        NODE_DATA() is updated, or before that pgdat is initialized,
        kernel might touch uninitialized pgdat.
        So, node_set_online() is called at final point. 
    
    The old kernel had pgdat->next link list, it was also critial point
    for hot-add. But current -mm remove it. So, it is not issue now. :-)

Thanks.

-- 
Yasunori Goto 


--
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>

  reply	other threads:[~2006-03-10  7:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-08 13:41 [PATCH: 000/017] (RFC)Memory hotplug for new nodes v.3 Yasunori Goto
2006-03-08 13:41 ` Yasunori Goto
2006-03-08 13:41 ` Yasunori Goto
2006-03-09 12:00 ` Andrew Morton
2006-03-09 12:00   ` Andrew Morton
2006-03-09 12:00   ` Andrew Morton
2006-03-10  7:13   ` Yasunori Goto [this message]
2006-03-10  7:13     ` Yasunori Goto
2006-03-10  7:13     ` Yasunori Goto

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=20060310145025.CA6F.Y-GOTO@jp.fujitsu.com \
    --to=y-goto@jp.fujitsu.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=haveblue@us.ibm.com \
    --cc=jschopp@austin.ibm.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tony.luck@intel.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 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.