Re: [PATCH] Prezeroing V8

[Christoph Lameter]

On Thu, 17 Mar 2005, Andrew Morton wrote:

> OK, so we're splitting each zone's buddy structure into two: one for zeroed
> pages and one for not-zeroed pages, yes?

Right.

> It's not obvious what the page->private of freed pages are being used for.
> Please comment that.

Ok.

> What's all this (zero << 10) stuff?
>
> +	page->private = order + (zero << 10);
> +           (page_zorder(page) == order + (zero << 10)) &&
>
> Doesn't this explode if we already have order-1024 pages in there?  I guess
> that's a reasonable restriction, but where did the "10" come from?
> Non-obvious, needs commenting.

Yes it will fail if we have pages of the size of 2^1036.

> And given that we have separate buddy structures for zeroed and not-zeroed
> pages, why is this tagging needed at all?

Because the buddy pointers may point to a page of the different kind. Then
a merge is not possible.

> These are all design decisions which have been made, but they're not
> communicated either in the patch description or in code comments.  It's to
> everyone's advantage to fix that, no?

Of course. Try to do this ASAP. Testing a patch that defines the
following:

Index: linux-2.6.11/include/linux/gfp.h
===================================================================
--- linux-2.6.11.orig/include/linux/gfp.h       2005-03-01
23:37:50.000000000 -0800
+++ linux-2.6.11/include/linux/gfp.h    2005-03-17 14:59:06.000000000
-0800
@@ -125,6 +125,8 @@ extern void FASTCALL(__free_pages(struct
 extern void FASTCALL(free_pages(unsigned long addr, unsigned int order));
 extern void FASTCALL(free_hot_page(struct page *page));
 extern void FASTCALL(free_cold_page(struct page *page));
+extern void FASTCALL(free_hot_zeroed_page(struct page *page));
+extern void FASTCALL(free_cold_zeroed_page(struct page *page));

 #define __free_page(page) __free_pages((page), 0)
 #define free_page(addr) free_pages((addr),0)

This is what you want right?

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