Message-ID: <20100310000121.GA9985@cmpxchg.org>
Date:	Wed, 10 Mar 2010 01:01:21 +0100
From:	Johannes Weiner <hannes@...xchg.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Yinghai Lu <yinghai@...nel.org>, x86@...nel.org,
	linux-arch@...nel.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: further plans on bootmem, was: Re: - bootmem-avoid-dma32-zone-by-default.patch removed from -mm tree

On Tue, Mar 09, 2010 at 01:49:02PM -0800, Andrew Morton wrote:
> On Tue, 09 Mar 2010 13:09:55 -0800
> Yinghai Lu <yinghai@...nel.org> wrote:
> 
> > On 03/09/2010 11:40 AM, akpm@...ux-foundation.org wrote:
> > > The patch titled
> > >      bootmem: avoid DMA32 zone by default
> > > has been removed from the -mm tree.  Its filename was
> > >      bootmem-avoid-dma32-zone-by-default.patch
> > > 
> > > This patch was dropped because I'm all confused
> > > 
> > 
> > Thanks for that...
> 
> Well.  I did drop it because I'm all confused.  It may come back.
> 
> If Johannes is working in the direction of removing and simplifying
> code then that's a high priority.  So I'm waiting to see where this
> discussion leads (on the mailing list, please!)

I am not working on simplifying in this area at the moment.  I am just
questioning the discrepancy between the motivation of Yinghai's patch
series to skip bootmem on x86 and its actual outcome.

The stated reason for the series was that the amount of memory allocators
involved in bootstrapping mm on x86 'seemed a bit excessive'. [1]

I am perfectly fine with the theory: select one mechanism and see whether
it can be bridged and consequently _removed_.  To shrink the code base,
shrink text size, make the boot process less complex, more robust etc.

What I take away from this patchset, however, is that all it really does
is make the early_res stuff from x86 generic code and add a semantically
different version of the bootmem API on top of it, selectable with a config
option.  The diffstat balance is an increase of around 900 lines of code.

Note that it still uses bootmem to actually bootstrap the page allocator,
that we now have two implementations of the bootmem interface and no real
plan - as far as I am informed - to actually change this.

I also found it weird that it makes x86 skip an allocator level that all
the other architectures are using, and replaces it with 'generic' code that
nobody but x86 is using (sparc, powerpc, sh and microblaze  appear to have
lib/lmb.c at this stage and for this purpose? lmb was also suggested by
benh [4] but I have to admit I do not understand Yinghai's response to it).

When I asked Yinghai for the benefits of this change, he responded with
this [2]:

nobootmem:                                                                                                                                   
   text    data     bss     dec     hex filename                                                                                             
19185736        4148404 12170736        35504876        21dc2ec vmlinux.nobootmem
Memory: 1058662820k/1075838976k available (11388k kernel code, 2106480k absent, 15069676k reserved, 8589k data, 2744k init
[  220.947157] calling  ip_auto_config+0x0/0x24d @ 1


bootmem:                   
   text    data     bss     dec     hex filename
19188441        4153956 12170736        35513133        21de32d vmlinux.bootmem
Memory: 1058662796k/1075838976k available (11388k kernel code, 2106480k absent, 15069700k reserved, 8589k data, 2752k init
[  236.765364] calling  ip_auto_config+0x0/0x24d @ 1

but compare this with the diffstat and memory savings of Joe Perches'
latest dev_<level> macro changes [3].

So the questions I still have is this: can early_res replace bootmem
for other architectures too (and will this be pushed!) or are we stuck
with two implementations of the bootmem API forever?

Or more generically, I can not see that this series is a complete act
of reduction but I also can not see what is supposed to follow up in
order to finish it.  And apparently I am not alone with this.  Can
Yinghai or somebody else of the x86 team shed some light on this?

Thanks.

	Hannes

PS: I think it is common practice on LKML that if you have plans for
a piece of code, you involve all its users and people who last worked
on it in the discussions.  So please check your Cc lists next time
before stuff is about to get merged.  Thanks again.

[1] http://archives.free.net.ph/message/20100209.193211.48e131c7.en.html
[2] http://lkml.org/lkml/2010/3/5/414
[3] http://lkml.org/lkml/2010/3/4/17
[4] http://lkml.org/lkml/2010/2/14/321
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists