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 <[email protected]>
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);
}
}
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
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
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
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
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
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
>>>>> "Linus" == Linus Torvalds <[email protected]> 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
On Mon, Jan 16, 2006 at 03:53:08AM -0500, Jes Sorensen wrote:
> >>>>> "Linus" == Linus Torvalds <[email protected]> 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