[patch] mm: cleanup bootmem

[patch] mm: cleanup bootmem

[Nick Piggin]

[-- Attachment #1: Type: text/plain, Size: 41 bytes --]

Objections?

-- 
SUSE Labs, Novell Inc.


[-- Attachment #2: mm-cleanup-bootmem.patch --]
[-- Type: text/plain, Size: 1761 bytes --]

The bootmem code added to page_alloc.c duplicated some page freeing code
that it really doesn't need to because it is not so performance critical.

While we're here, make prefetching work properly by actually prefetching
the page we're about to use before prefetching ahead to the next one (ie.
get the most important transaction started first). Also prefetch just a
single page ahead rather than leaving a gap of 16.

Signed-off-by: Nick Piggin <npiggin@suse.de>

Index: linux-2.6/mm/page_alloc.c
===================================================================
--- linux-2.6.orig/mm/page_alloc.c
+++ linux-2.6/mm/page_alloc.c
@@ -55,8 +55,6 @@ unsigned long totalhigh_pages __read_mos
 long nr_swap_pages;
 int percpu_pagelist_fraction;
 
-static void fastcall free_hot_cold_page(struct page *page, int cold);
-
 /*
  * results with 256, 32 in the lowmem_reserve sysctl:
  *	1G machine -> (16M dma, 800M-16M normal, 1G-800M high)
@@ -444,28 +442,23 @@ void fastcall __init __free_pages_bootme
 	if (order == 0) {
 		__ClearPageReserved(page);
 		set_page_count(page, 0);
-
-		free_hot_cold_page(page, 0);
+		set_page_refs(page, 0);
+		__free_page(page);
 	} else {
-		LIST_HEAD(list);
 		int loop;
 
+		prefetchw(page);
 		for (loop = 0; loop < BITS_PER_LONG; loop++) {
 			struct page *p = &page[loop];
 
-			if (loop + 16 < BITS_PER_LONG)
-				prefetchw(p + 16);
+			if (loop + 1 < BITS_PER_LONG)
+				prefetchw(p + 1);
 			__ClearPageReserved(p);
 			set_page_count(p, 0);
 		}
 
-		arch_free_page(page, order);
-
-		mod_page_state(pgfree, 1 << order);
-
-		list_add(&page->lru, &list);
-		kernel_map_pages(page, 1 << order, 0);
-		free_pages_bulk(page_zone(page), 1, &list, order);
+		set_page_refs(page, order);
+		__free_pages(page, order);
 	}
 }
 

Re: [patch] mm: cleanup bootmem

[Nick Piggin]

Nick Piggin wrote:
> Objections?
> 
> 
> ------------------------------------------------------------------------
> 
> The bootmem code added to page_alloc.c duplicated some page freeing code
> that it really doesn't need to because it is not so performance critical.
> 

... but actually it is possible that it ends up being faster with this
patch anyway, due to the old code freeing the pages as higher order
batches: they won't have to go through as many iterations in the buddy
allocator. This patch restores that behaviour as well.

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [patch] mm: cleanup bootmem

[Linus Torvalds]

On Sat, 14 Jan 2006, Nick Piggin wrote:
>
> Objections?

The whole point of the pre-batching was that apparently the non-batched 
bootmem code took ages to boot in simulation with lots of memory. I think 
it was the ia64 people who used simulation a lot. So..

		Linus

Re: [patch] mm: cleanup bootmem

[Nick Piggin]

Linus Torvalds wrote:
> 
> On Sat, 14 Jan 2006, Nick Piggin wrote:
> 
>>Objections?
> 
> 
> The whole point of the pre-batching was that apparently the non-batched 
> bootmem code took ages to boot in simulation with lots of memory. I think 
> it was the ia64 people who used simulation a lot. So..
> 
> 		Linus
> 

Changelog doesn't mention it: a226f6c899799fe2c4919daa0767ac579c88f7bd

Or... what do you mean by pre-batching? (maybe I'm confused and you're
talking about my prefetching change or something)

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [patch] mm: cleanup bootmem

[Nick Piggin]

Nick Piggin wrote:
> Linus Torvalds wrote:
> 
>>
>> On Sat, 14 Jan 2006, Nick Piggin wrote:
>>
>>> Objections?
>>
>>
>>
>> The whole point of the pre-batching was that apparently the 
>> non-batched bootmem code took ages to boot in simulation with lots of 
>> memory. I think it was the ia64 people who used simulation a lot. So..
>>
>>         Linus
>>
> 
> Changelog doesn't mention it: a226f6c899799fe2c4919daa0767ac579c88f7bd
> 
> Or... what do you mean by pre-batching? (maybe I'm confused and you're
> talking about my prefetching change or something)
> 

Oh the BITS_PER_LONG batching? That's still completely functional after
my patch. In fact, as I said in a followup it is likely to work better
than with David's change to free batched pages as order-0, because I
reverted back to freeing them as higher order pages.

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [patch] mm: cleanup bootmem

[Linus Torvalds]

On Sun, 15 Jan 2006, Nick Piggin wrote:
> 
> Oh the BITS_PER_LONG batching?

Yes.

>			 That's still completely functional after
> my patch. In fact, as I said in a followup it is likely to work better
> than with David's change to free batched pages as order-0, because I
> reverted back to freeing them as higher order pages.

Ok. Then I doubt anybody will complain. I'm still wondering if some of the 
other ugliness was due to some simulator strangeness issues, but maybe 
even ia64 doesn't care that much any more..

		Linus

Re: [patch] mm: cleanup bootmem

[Nick Piggin]

Linus Torvalds wrote:
> 
> On Sun, 15 Jan 2006, Nick Piggin wrote:
> 
>>Oh the BITS_PER_LONG batching?
> 
> 
> Yes.
> 
> 
>>			 That's still completely functional after
>>my patch. In fact, as I said in a followup it is likely to work better
>>than with David's change to free batched pages as order-0, because I
>>reverted back to freeing them as higher order pages.
> 
> 
> Ok. Then I doubt anybody will complain. I'm still wondering if some of the 
> other ugliness was due to some simulator strangeness issues, but maybe 

I'm a little unsure. That's what I suspected when I saw David's
changeset was part of an FRV: prefixed batch but wasn't directly
related to FRV code. (ie. normally such a patch would be mm: or
bootmem:)

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [patch] mm: cleanup bootmem

[Jes Sorensen]

>>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:

Linus> On Sun, 15 Jan 2006, Nick Piggin wrote:
>> That's still completely functional after my patch. In fact, as I
>> said in a followup it is likely to work better than with David's
>> change to free batched pages as order-0, because I reverted back to
>> freeing them as higher order pages.

Linus> Ok. Then I doubt anybody will complain. I'm still wondering if
Linus> some of the other ugliness was due to some simulator
Linus> strangeness issues, but maybe even ia64 doesn't care that much
Linus> any more..

We still use simulators for a bunch of stuff, but I don't know if this
is affecting it or not. Jack Steiner may know more.

Cheers,
Jes

Re: [patch] mm: cleanup bootmem

[Jack Steiner]

On Mon, Jan 16, 2006 at 03:53:08AM -0500, Jes Sorensen wrote:
> >>>>> "Linus" == Linus Torvalds <torvalds@osdl.org> writes:
> 
> Linus> On Sun, 15 Jan 2006, Nick Piggin wrote:
> >> That's still completely functional after my patch. In fact, as I
> >> said in a followup it is likely to work better than with David's
> >> change to free batched pages as order-0, because I reverted back to
> >> freeing them as higher order pages.
> 
> Linus> Ok. Then I doubt anybody will complain. I'm still wondering if
> Linus> some of the other ugliness was due to some simulator
> Linus> strangeness issues, but maybe even ia64 doesn't care that much
> Linus> any more..
> 
> We still use simulators for a bunch of stuff, but I don't know if this
> is affecting it or not. Jack Steiner may know more.

AFAICT, the patch doesnt affect the simulator that is used at SGI. I
built a current tree, applied the patch & booted ok. No problems.

> 
> Cheers,
> Jes

--
Thanks

Jack