linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [patch] mm: cleanup bootmem
@ 2006-01-14 12:42 Nick Piggin
  2006-01-14 12:47 ` Nick Piggin
  2006-01-14 17:50 ` Linus Torvalds
  0 siblings, 2 replies; 9+ messages in thread
From: Nick Piggin @ 2006-01-14 12:42 UTC (permalink / raw)
  To: Andrew Morton, David Howells; +Cc: Linus Torvalds, Linux Kernel Mailing List

[-- 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);
 	}
 }
 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] mm: cleanup bootmem
  2006-01-14 12:42 [patch] mm: cleanup bootmem Nick Piggin
@ 2006-01-14 12:47 ` Nick Piggin
  2006-01-14 17:50 ` Linus Torvalds
  1 sibling, 0 replies; 9+ messages in thread
From: Nick Piggin @ 2006-01-14 12:47 UTC (permalink / raw)
  To: Andrew Morton; +Cc: David Howells, Linus Torvalds, Linux Kernel Mailing List

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 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] mm: cleanup bootmem
  2006-01-14 12:42 [patch] mm: cleanup bootmem Nick Piggin
  2006-01-14 12:47 ` Nick Piggin
@ 2006-01-14 17:50 ` Linus Torvalds
  2006-01-14 18:02   ` Nick Piggin
  1 sibling, 1 reply; 9+ messages in thread
From: Linus Torvalds @ 2006-01-14 17:50 UTC (permalink / raw)
  To: Nick Piggin; +Cc: Andrew Morton, David Howells, Linux Kernel Mailing List



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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] mm: cleanup bootmem
  2006-01-14 17:50 ` Linus Torvalds
@ 2006-01-14 18:02   ` Nick Piggin
  2006-01-14 18:06     ` Nick Piggin
  0 siblings, 1 reply; 9+ messages in thread
From: Nick Piggin @ 2006-01-14 18:02 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Andrew Morton, David Howells, Linux Kernel Mailing List

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 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] mm: cleanup bootmem
  2006-01-14 18:02   ` Nick Piggin
@ 2006-01-14 18:06     ` Nick Piggin
  2006-01-14 18:13       ` Linus Torvalds
  0 siblings, 1 reply; 9+ messages in thread
From: Nick Piggin @ 2006-01-14 18:06 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Andrew Morton, David Howells, Linux Kernel Mailing List

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 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] mm: cleanup bootmem
  2006-01-14 18:06     ` Nick Piggin
@ 2006-01-14 18:13       ` Linus Torvalds
  2006-01-14 18:43         ` Nick Piggin
  2006-01-16  8:53         ` Jes Sorensen
  0 siblings, 2 replies; 9+ messages in thread
From: Linus Torvalds @ 2006-01-14 18:13 UTC (permalink / raw)
  To: Nick Piggin; +Cc: Andrew Morton, David Howells, Linux Kernel Mailing List



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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] mm: cleanup bootmem
  2006-01-14 18:13       ` Linus Torvalds
@ 2006-01-14 18:43         ` Nick Piggin
  2006-01-16  8:53         ` Jes Sorensen
  1 sibling, 0 replies; 9+ messages in thread
From: Nick Piggin @ 2006-01-14 18:43 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Andrew Morton, David Howells, Linux Kernel Mailing List

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 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] mm: cleanup bootmem
  2006-01-14 18:13       ` Linus Torvalds
  2006-01-14 18:43         ` Nick Piggin
@ 2006-01-16  8:53         ` Jes Sorensen
  2006-01-16 15:25           ` Jack Steiner
  1 sibling, 1 reply; 9+ messages in thread
From: Jes Sorensen @ 2006-01-16  8:53 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Nick Piggin, Andrew Morton, David Howells,
	Linux Kernel Mailing List, Jack Steiner

>>>>> "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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch] mm: cleanup bootmem
  2006-01-16  8:53         ` Jes Sorensen
@ 2006-01-16 15:25           ` Jack Steiner
  0 siblings, 0 replies; 9+ messages in thread
From: Jack Steiner @ 2006-01-16 15:25 UTC (permalink / raw)
  To: Jes Sorensen
  Cc: Linus Torvalds, Nick Piggin, Andrew Morton, David Howells,
	Linux Kernel Mailing List

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2006-01-16 15:26 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-14 12:42 [patch] mm: cleanup bootmem Nick Piggin
2006-01-14 12:47 ` Nick Piggin
2006-01-14 17:50 ` Linus Torvalds
2006-01-14 18:02   ` Nick Piggin
2006-01-14 18:06     ` Nick Piggin
2006-01-14 18:13       ` Linus Torvalds
2006-01-14 18:43         ` Nick Piggin
2006-01-16  8:53         ` Jes Sorensen
2006-01-16 15:25           ` Jack Steiner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).