[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1272650547.10027.97.camel@useless.americas.hpqcorp.net>
Date: Fri, 30 Apr 2010 14:02:27 -0400
From: Lee Schermerhorn <Lee.Schermerhorn@...com>
To: Valdis.Kletnieks@...edu
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: mmotm 2010-04-28-16-53 uploaded
On Thu, 2010-04-29 at 17:32 -0400, Valdis.Kletnieks@...edu wrote:
> On Wed, 28 Apr 2010 16:53:32 PDT, akpm@...ux-foundation.org said:
> > The mm-of-the-moment snapshot 2010-04-28-16-53 has been uploaded to
> >
> > http://userweb.kernel.org/~akpm/mmotm/
>
> Dies trying to compile mm/slab.c because something screwed the pooch with
> the definition of numa_mem_id(). My bets are on
> numa-slab-use-numa_mem_id-for-slab-local-memory-node.patch
>
Vlad:
Would you have time to try a few patches? I've been doing some rework
of the generic percpu numa_node/numa_mem patches. This rework should
solve the build problem you encountered.
The patch you cite:
numa-slab-use-numa_mem_id-for-slab-local-memory-node.patch
is the immediate cause of the build failure, but it's really the earlier
patches--definitions of numa_node_id() and numa_mem_id()--that are
causing it.
I have attached a tarball containing a number of incremental patches to
the numa-* patches in 22apr or 28apr mmotm. Should be fairly obvious
from the name where they fit into the series. The tarball includes
Andrew's fix to the previous build problem you encountered [missing
paren]. That fix is already in the 28apr mmotm.
These patches build, boot and run on x86_64 and ia64. I also built
x86-64 mm/slab.o with !NUMA and an i386 kernel cross-compile with the
config that Andrew sent out.
I hope to post the individual patches to the mailing lists for review
later today. The tarball should give you a head start if you're
interested.
Lee
Download attachment "nid_rework-2.6.34-rc5-mmotm-100428-1653-100430.tar.gz" of type "application/x-compressed-tar" (6797 bytes)
Powered by blists - more mailing lists