Mailing List Archive: Linux: Kernel

[patch 00/10] (no)bootmem bits for 3.5

Index | Next | Previous | View Threaded

hannes at cmpxchg

May 7, 2012, 4:37 AM

Post #1 of 7 (89 views)
Permalink

[patch 00/10] (no)bootmem bits for 3.5

Hi,

here are some (no)bootmem fixes and cleanups for 3.5. Most of it is
unifying allocation behaviour across bootmem and nobootmem when it
comes to respecting the specified allocation address goal and numa.

But also refactoring the codebases of the two bootmem APIs so that we
can think about sharing code between them again.

include/linux/bootmem.h | 3 ---
mm/bootmem.c | 118 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------------------------------------
mm/nobootmem.c | 112 ++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------------------------
mm/sparse.c | 25 ++++++++++++-------------
4 files changed, 127 insertions(+), 131 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

sam at ravnborg

May 7, 2012, 1:41 PM

Post #2 of 7 (86 views)
Permalink

Re: [patch 00/10] (no)bootmem bits for 3.5 [In reply to]

Hi Johannes.

> here are some (no)bootmem fixes and cleanups for 3.5. Most of it is
> unifying allocation behaviour across bootmem and nobootmem when it
> comes to respecting the specified allocation address goal and numa.
>
> But also refactoring the codebases of the two bootmem APIs so that we
> can think about sharing code between them again.

Could you check up on CONFIG_HAVE_ARCH_BOOTMEM use in bootmem.c too?
x86 no longer uses bootmem.c
avr define it - but to n.

So no-one is actually using this anymore.
I have sent patches to remove it from Kconfig for both x86 and avr.

I looked briefly at cleaning up bootmem.c myslef - but I felt not
familiar enough with the code to do the cleanup.

I did not check your patchset - but based on the shortlog you
did not kill HAVE_ARCH_BOOTMEM.

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

hannes at cmpxchg

May 7, 2012, 3:01 PM

Post #3 of 7 (84 views)
Permalink

Re: [patch 00/10] (no)bootmem bits for 3.5 [In reply to]

On Mon, May 07, 2012 at 10:41:13PM +0200, Sam Ravnborg wrote:
> Hi Johannes.
>
> > here are some (no)bootmem fixes and cleanups for 3.5. Most of it is
> > unifying allocation behaviour across bootmem and nobootmem when it
> > comes to respecting the specified allocation address goal and numa.
> >
> > But also refactoring the codebases of the two bootmem APIs so that we
> > can think about sharing code between them again.
>
> Could you check up on CONFIG_HAVE_ARCH_BOOTMEM use in bootmem.c too?
> x86 no longer uses bootmem.c
> avr define it - but to n.
>
> So no-one is actually using this anymore.
> I have sent patches to remove it from Kconfig for both x86 and avr.
>
> I looked briefly at cleaning up bootmem.c myslef - but I felt not
> familiar enough with the code to do the cleanup.
>
> I did not check your patchset - but based on the shortlog you
> did not kill HAVE_ARCH_BOOTMEM.

It was used on x86-32 numa to try all bootmem allocations from node 0
first (see only remaining definition of bootmem_arch_preferred_node),
which AFAICS nobootmem no longer respects.

Shouldn't this be fixed instead?

But yeah, we can remove the bootmem.c parts, I think.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

sam at ravnborg

May 8, 2012, 10:57 AM

Post #4 of 7 (83 views)
Permalink

Re: [patch 00/10] (no)bootmem bits for 3.5 [In reply to]

On Tue, May 08, 2012 at 12:01:42AM +0200, Johannes Weiner wrote:
> On Mon, May 07, 2012 at 10:41:13PM +0200, Sam Ravnborg wrote:
> > Hi Johannes.
> >
> > > here are some (no)bootmem fixes and cleanups for 3.5. Most of it is
> > > unifying allocation behaviour across bootmem and nobootmem when it
> > > comes to respecting the specified allocation address goal and numa.
> > >
> > > But also refactoring the codebases of the two bootmem APIs so that we
> > > can think about sharing code between them again.
> >
> > Could you check up on CONFIG_HAVE_ARCH_BOOTMEM use in bootmem.c too?
> > x86 no longer uses bootmem.c
> > avr define it - but to n.
> >
> > So no-one is actually using this anymore.
> > I have sent patches to remove it from Kconfig for both x86 and avr.
> >
> > I looked briefly at cleaning up bootmem.c myslef - but I felt not
> > familiar enough with the code to do the cleanup.
> >
> > I did not check your patchset - but based on the shortlog you
> > did not kill HAVE_ARCH_BOOTMEM.
>
> It was used on x86-32 numa to try all bootmem allocations from node 0
> first (see only remaining definition of bootmem_arch_preferred_node),
> which AFAICS nobootmem no longer respects.
>
> Shouldn't this be fixed instead?
I do not know. Tejun / Yinghai?

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

tj at kernel

May 9, 2012, 10:35 AM

Post #5 of 7 (77 views)
Permalink

Re: [patch 00/10] (no)bootmem bits for 3.5 [In reply to]

Hello,

On Tue, May 08, 2012 at 07:57:48PM +0200, Sam Ravnborg wrote:
> > It was used on x86-32 numa to try all bootmem allocations from node 0
> > first (see only remaining definition of bootmem_arch_preferred_node),
> > which AFAICS nobootmem no longer respects.
> >
> > Shouldn't this be fixed instead?
> I do not know. Tejun / Yinghai?

Indeed, preferring node 0 for bootmem allocation on x86_32 got lost
across the nobootmem changes. I followed the git history and
preferring NODE_DATA(0) goes back to the initial git branch creation
time (2.6.12) and I couldn't find any explanation, and nobody
complained about the changed behavior. hpa, do you know why the code
to prefer node 0 for bootmem allocations was added in the first place?
Maybe we can just remove it?

Thanks.

--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

cl at linux

May 9, 2012, 10:54 AM

Post #6 of 7 (77 views)
Permalink

Re: [patch 00/10] (no)bootmem bits for 3.5 [In reply to]

On Wed, 9 May 2012, Tejun Heo wrote:

> Indeed, preferring node 0 for bootmem allocation on x86_32 got lost
> across the nobootmem changes. I followed the git history and
> preferring NODE_DATA(0) goes back to the initial git branch creation
> time (2.6.12) and I couldn't find any explanation, and nobody
> complained about the changed behavior. hpa, do you know why the code
> to prefer node 0 for bootmem allocations was added in the first place?
> Maybe we can just remove it?

On some early 32 bit NUMA platforms only node 0 had ZONE_NORMAL memory.
There is just no other ZONE_NORMAL memory available on other nodes on that
hardware. But that is ancient history.

Wondering if 32 bit numa machines still exist. If so how do they partition
memory below 1G?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

tj at kernel

May 9, 2012, 11:08 AM

Post #7 of 7 (77 views)
Permalink

Re: [patch 00/10] (no)bootmem bits for 3.5 [In reply to]

Hello, Christoph.

On Wed, May 09, 2012 at 12:54:37PM -0500, Christoph Lameter wrote:
> On some early 32 bit NUMA platforms only node 0 had ZONE_NORMAL memory.
> There is just no other ZONE_NORMAL memory available on other nodes on that
> hardware. But that is ancient history.

I see, but that shouldn't matter (at least anymore), the allocator can
fall back to other nodes just fine and there's no reason to
preemptively prefer node 0.

Thanks.

--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads