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>
prev parent reply other threads:[~2007-09-14 20:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-11 7:25 Paul Mundt
2007-09-11 8:18 ` Yasunori Goto
2007-09-11 8:25 ` Paul Mundt
2007-09-11 9:15 ` Andy Whitcroft
2007-09-11 9:37 ` Yasunori Goto
2007-09-14 1:44 ` Andrew Morton
2007-09-14 2:02 ` Yasunori Goto
2007-09-14 2:41 ` Andrew Morton
2007-09-14 5:14 ` Yasunori Goto
2007-09-14 14:09 ` Lee Schermerhorn
2007-09-14 20:51 ` Andrew Morton [this message]
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox