mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dave Hansen <dave@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Yasunori Goto <y-goto@jp.fujitsu.com>,
	Christoph Lameter <clameter@sgi.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] hotplug-memory: refactor online_pages to separate zone growth from page onlining
Date: Fri, 28 Mar 2008 17:47:02 -0700	[thread overview]
Message-ID: <1206751622.27091.20.camel@nimitz.home.sr71.net> (raw)
In-Reply-To: <47ED8685.9040409@goop.org>

On Fri, 2008-03-28 at 17:00 -0700, Jeremy Fitzhardinge wrote:
> The Xen balloon driver needs to separate the process of hot-installing
> memory into two phases: one to allocate the page structures and
> configure the zones, and another to actually online the pages of newly
> installed memory.
> 
> This patch splits up the innards of online_pages() into two pieces which
> correspond to these two phases.  The behaviour of online_pages() itself
> is unchanged.
...
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -180,31 +180,35 @@
>         return 0;
>  }
> 
> -
> -int online_pages(unsigned long pfn, unsigned long nr_pages)
> +/* Tell anyone who's interested that we're onlining some memory */
> +static int notify_going_online(unsigned long pfn, unsigned long nr_pages)
>  {
> -       unsigned long flags;
> -       unsigned long onlined_pages = 0;
> -       struct zone *zone;
> -       int need_zonelists_rebuild = 0;
> +       struct memory_notify arg;
>         int nid;
>         int ret;
> -       struct memory_notify arg;
> 
>         arg.start_pfn = pfn;
>         arg.nr_pages = nr_pages;
>         arg.status_change_nid = -1;
> -
> +
>         nid = page_to_nid(pfn_to_page(pfn));
>         if (node_present_pages(nid) == 0)
>                 arg.status_change_nid = nid;

That's kind a weird line in the patch.  How'd that get there?  Why are
you moving 'arg'?

This look OK, but it does add ~45 lines of code, and I'm not immediately
sure how you're going to use it.  Could you address that a bit?

I do kinda wish you'd take a real hard look at what the new functions
are doing now.  I'm not sure their current names are very good.

> +/* Grow the zone to fit the expected amount of memory being added */
> +static struct zone *online_pages_zone(unsigned long pfn, unsigned long nr_pages)

The comment is good, but the function name is not. :)  How about
grow_zone_span() or something?

> +/* Mark a set of pages as online */
> +unsigned long mark_pages_onlined(unsigned long pfn, unsigned long nr_pages)

Isn't the comment on this one a bit redundant? :)

This looks to me to have become the real online_pages() now.  This
function is what goes and individually onlines pages.  If someone was
trying to figure out whether to call online_pages() or
mark_pages_onlined(), which one would they know to call?

> -       if (onlined_pages)
> +       if (onlined_pages) {
> +               struct memory_notify arg;
> +
> +               arg.start_pfn = pfn;  /* ? */
> +               arg.nr_pages = onlined_pages;
> +               arg.status_change_nid = -1;  /* ? */
> +
>                 memory_notify(MEM_ONLINE, &arg);
> +       }

We should really wrap up memory notify:

static void memory_notify(int state, unsigned long start_pfn,
			  unsigned long nr_pages, int status_change_nid)
{
	struct memory_notify arg;
	arg.start_pfn = start_pfn;
	arg.nr_pages = nr_pages;
	arg.status_change_nid = status_change_nid;
	return the_current_memory_notify(state, &arg);
}

We can use that in a couple of spots, right?

-- Dave


  reply	other threads:[~2008-03-29  0:47 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-29  0:00 Jeremy Fitzhardinge
2008-03-29  0:47 ` Dave Hansen [this message]
2008-03-29  2:08   ` Jeremy Fitzhardinge
2008-03-29  6:01     ` Dave Hansen
2008-03-29 16:06     ` Dave Hansen
2008-03-29 23:53       ` Jeremy Fitzhardinge
2008-03-30  0:26         ` Anthony Liguori
2008-03-31 16:42         ` Dave Hansen
2008-03-31 18:06           ` Jeremy Fitzhardinge
2008-04-01  7:17             ` Yasunori Goto
2008-04-02 18:46             ` Dave Hansen
2008-04-02 18:52               ` Jeremy Fitzhardinge
2008-04-02 18:59                 ` Dave Hansen
2008-04-02 21:03                   ` Jeremy Fitzhardinge
2008-04-02 21:17                     ` Dave Hansen
2008-04-02 21:35                       ` Jeremy Fitzhardinge
2008-04-02 21:43                         ` Dave Hansen
2008-04-02 22:13                           ` Jeremy Fitzhardinge
2008-04-02 23:27                             ` Dave Hansen
2008-04-03  7:03                             ` KAMEZAWA Hiroyuki
2008-04-02 21:36                       ` Anthony Liguori
2008-03-29  4:38 ` KAMEZAWA Hiroyuki
2008-03-29  5:48   ` Jeremy Fitzhardinge
2008-03-29  6:26     ` KAMEZAWA Hiroyuki

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=1206751622.27091.20.camel@nimitz.home.sr71.net \
    --to=dave@linux.vnet.ibm.com \
    --cc=clameter@sgi.com \
    --cc=jeremy@goop.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=y-goto@jp.fujitsu.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

all inboxes | Powered by JetHome®