Date: Sat, 30 Oct 2004 14:07:32 -0700
From: Andrew Morton <akpm@osdl.org>
To: Andrea Arcangeli <andrea@novell.com>
Cc: nickpiggin@yahoo.com.au, linux-kernel@vger.kernel.org
Subject: Re: PG_zero
Message-Id: <20041030140732.2ccc7d22.akpm@osdl.org>
In-Reply-To: <20041030141059.GA16861@dualathlon.random>
References: <20041030141059.GA16861@dualathlon.random>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1232
Lines: 29

Andrea Arcangeli <andrea@novell.com> wrote:
>
> I think it's much better to have PG_zero in the main page allocator than
>  to put the ptes in the slab. This way we can share available zero pages with
>  all zero-page users and we have a central place where people can
>  generate zero pages and allocate them later efficiently.

Yup.

>  This gives a whole internal knowledge to the whole buddy system and
>  per-cpu subsystem of zero pages.

Makes sense.  I had a go at this ages ago and wasn't able to demonstrate
much benefit on a mixed workload.

I wonder if it would help if the page zeroing in the idle thread was done
with the CPU cache disabled.  It should be pretty easy to test - isn't it
just a matter of setting the cache-disable bit in the kmap_atomic()
operation?

There are quite a few patches happening in this area - the
make-kswapd-aware-of-higher-order-pages patches and the no-buddy-bitmap
patches are queued in -mm.  It'll take some time to work through them
all...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/