All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: Yasunori Goto <y-goto@jp.fujitsu.com>,
	Andy Whitcroft <apw@shadowen.org>,
	Paul Mundt <lethal@linux-sh.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH -mm] mm: Fix memory hotplug + sparsemem build.
Date: Fri, 14 Sep 2007 13:51:54 -0700	[thread overview]
Message-ID: <20070914135154.bc60742e.akpm@linux-foundation.org> (raw)
In-Reply-To: <1189778967.5315.11.camel@localhost>

On Fri, 14 Sep 2007 10:09:27 -0400
Lee Schermerhorn <Lee.Schermerhorn@hp.com> wrote:

> I originally sent in the "update-n_high_memory..." patch against
> 23-rc3-mm1 on 27aug to fix a problem that I introduced when I moved the
> populating of N_HIGH_MEMORY state to free_area_init_nodes().  This would
> miss setting the "has memory" node state for hot added memory.  I never
> saw any response, but then it ended up in 23-rc4-mm1.
> 
> This Tuesday, Paul Mundt sent in a patch to fix a build problem with
> MEMORY_HOTPLUG_SPARSE introduced by my patch.  He replaced zone->node
> with zone_to_nid(zone) in the node_set_state() arguments.
> 
> The latest patch, from Yasunori-san, I believe, starts kswapd for nodes
> to which memory has been hot-added.  As I understand it, his is needed
> because the memoryless nodes patch results in no kswapd for memoryless
> nodes.
> 
> Does that help?

not really ;)

See, when I get some rinky-dink little fix for a patch in -mm I will
position that patch immediately after the patch which it is fixing, with a
filename which is derived from the fixed patch's name.  So when
send-to-Linus time comes, I can fold the fixes into the base patch.  This
practice also keeps the patches in a sensible presentation order, with
minimum interdependencies and good git-bisect friendliness.

However it sometimes (rarely) takes considerable effort to work out which
patch in -mm a particular fix is fixing.  That was the case with
update-n_high_memory-node-state-for-memory-hotadd.patch.

It helps me quite a bit if people tell me which patch they're fixing. 
Usually they don't and I get to work it out.  Usually it's fairly obvious.


WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Cc: Yasunori Goto <y-goto@jp.fujitsu.com>,
	Andy Whitcroft <apw@shadowen.org>,
	Paul Mundt <lethal@linux-sh.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH -mm] mm: Fix memory hotplug + sparsemem build.
Date: Fri, 14 Sep 2007 13:51:54 -0700	[thread overview]
Message-ID: <20070914135154.bc60742e.akpm@linux-foundation.org> (raw)
In-Reply-To: <1189778967.5315.11.camel@localhost>

On Fri, 14 Sep 2007 10:09:27 -0400
Lee Schermerhorn <Lee.Schermerhorn@hp.com> wrote:

> I originally sent in the "update-n_high_memory..." patch against
> 23-rc3-mm1 on 27aug to fix a problem that I introduced when I moved the
> populating of N_HIGH_MEMORY state to free_area_init_nodes().  This would
> miss setting the "has memory" node state for hot added memory.  I never
> saw any response, but then it ended up in 23-rc4-mm1.
> 
> This Tuesday, Paul Mundt sent in a patch to fix a build problem with
> MEMORY_HOTPLUG_SPARSE introduced by my patch.  He replaced zone->node
> with zone_to_nid(zone) in the node_set_state() arguments.
> 
> The latest patch, from Yasunori-san, I believe, starts kswapd for nodes
> to which memory has been hot-added.  As I understand it, his is needed
> because the memoryless nodes patch results in no kswapd for memoryless
> nodes.
> 
> Does that help?

not really ;)

See, when I get some rinky-dink little fix for a patch in -mm I will
position that patch immediately after the patch which it is fixing, with a
filename which is derived from the fixed patch's name.  So when
send-to-Linus time comes, I can fold the fixes into the base patch.  This
practice also keeps the patches in a sensible presentation order, with
minimum interdependencies and good git-bisect friendliness.

However it sometimes (rarely) takes considerable effort to work out which
patch in -mm a particular fix is fixing.  That was the case with
update-n_high_memory-node-state-for-memory-hotadd.patch.

It helps me quite a bit if people tell me which patch they're fixing. 
Usually they don't and I get to work it out.  Usually it's fairly obvious.

--
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:[~2007-09-14 20:52 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-11  7:25 [PATCH -mm] mm: Fix memory hotplug + sparsemem build Paul Mundt
2007-09-11  7:25 ` Paul Mundt
2007-09-11  8:18 ` Yasunori Goto
2007-09-11  8:18   ` Yasunori Goto
2007-09-11  8:25   ` Paul Mundt
2007-09-11  8:25     ` Paul Mundt
2007-09-11  9:15   ` Andy Whitcroft
2007-09-11  9:15     ` Andy Whitcroft
2007-09-11  9:37     ` Yasunori Goto
2007-09-11  9:37       ` Yasunori Goto
2007-09-14  1:44       ` Andrew Morton
2007-09-14  1:44         ` Andrew Morton
2007-09-14  2:02         ` Yasunori Goto
2007-09-14  2:02           ` Yasunori Goto
2007-09-14  2:41           ` Andrew Morton
2007-09-14  2:41             ` Andrew Morton
2007-09-14  5:14             ` Yasunori Goto
2007-09-14  5:14               ` Yasunori Goto
2007-09-14 14:09             ` Lee Schermerhorn
2007-09-14 14:09               ` Lee Schermerhorn
2007-09-14 20:51               ` Andrew Morton [this message]
2007-09-14 20:51                 ` Andrew Morton

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=20070914135154.bc60742e.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=Lee.Schermerhorn@hp.com \
    --cc=apw@shadowen.org \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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 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.