From: Andy Whitcroft <apw@shadowen.org>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: Andrew Morton <akpm@osdl.org>,
Andrea Arcangeli <andrea@novell.com>,
nickpiggin@yahoo.com.au, linux-kernel@vger.kernel.org
Subject: Re: PG_zero
Date: Tue, 02 Nov 2004 13:53:09 +0000 [thread overview]
Message-ID: <41879145.7090309@shadowen.org> (raw)
In-Reply-To: <40860000.1099235861@[10.10.2.4]>
Martin J. Bligh wrote:
> --Andrew Morton <akpm@osdl.org> wrote (on Saturday, October 30, 2004 14:07:32 -0700):
>
>
>>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?
>
>
> I looked at the basic problem a couple of years ago (based on your own code,
> IIRC Andrew) then Andy (cc'ed) did it again with cache writethrough. It
> doesn't provide any benefit at all, no matter what we did, and it was
> finally ditched.
>
> I wouldn't bother doing it again personally ... perhaps Andy still has
> the last set of results he can send to you.
I'll have a look out for the results, they should be around somewhere?
The work I did was based on the idea it _had_ to be more efficient to
have pre-zero'd pages available instead of wasting the hot pages,
scrubbing them on use. I did a lot of work to introduce a new queue for
these, per-cpu. Scrubbing them using spare cycles, even trying a
version where we didn't polute the cache with them using uncached
write-combining. The results all showed (on i386 machines at least)
that the predominant cost was cache warmth. It was slower to fetch the
clean zero page from memory than it was to clean out all of the cache
page for use. The colder the page the slower the system went.
-apw
next prev parent reply other threads:[~2004-11-02 15:10 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-30 14:10 PG_zero Andrea Arcangeli
2004-10-30 21:07 ` PG_zero Andrew Morton
2004-10-30 22:45 ` PG_zero Andrea Arcangeli
2004-10-31 15:35 ` PG_zero Martin J. Bligh
2004-11-01 21:57 ` PG_zero Andrea Arcangeli
2004-11-01 22:05 ` PG_zero Martin J. Bligh
2004-11-02 3:41 ` PG_zero William Lee Irwin III
2004-10-31 15:17 ` PG_zero Martin J. Bligh
2004-11-02 13:53 ` Andy Whitcroft [this message]
2004-11-02 19:39 ` PG_zero Andrea Arcangeli
2004-11-01 17:26 ` PG_zero Nick Piggin
2004-11-01 18:03 ` PG_zero Martin J. Bligh
2004-11-01 22:34 ` PG_zero Andrea Arcangeli
2004-11-01 23:47 ` PG_zero Martin J. Bligh
2004-11-02 1:47 ` PG_zero Nick Piggin
2004-11-02 2:21 ` PG_zero Andrea Arcangeli
2004-11-02 2:54 ` PG_zero Nick Piggin
2004-11-02 15:42 ` PG_zero Martin J. Bligh
2004-11-02 19:50 ` PG_zero Andrea Arcangeli
2004-11-02 22:41 ` PG_zero Martin J. Bligh
2004-11-03 1:26 ` PG_zero Andrea Arcangeli
2004-11-02 21:09 ` PG_zero Andrew Morton
2004-11-02 21:56 ` PG_zero Andrea Arcangeli
2004-11-02 22:41 ` PG_zero Martin J. Bligh
2004-11-03 1:09 ` PG_zero Andrea Arcangeli
2004-11-03 1:18 ` PG_zero Martin J. Bligh
2004-11-03 1:23 ` PG_zero Nick Piggin
2004-11-03 2:05 ` PG_zero Andrea Arcangeli
2004-11-03 11:53 ` PG_zero Andrea Arcangeli
2004-11-03 12:10 ` PG_zero Pavel Machek
2004-11-01 22:24 ` PG_zero Andrea Arcangeli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41879145.7090309@shadowen.org \
--to=apw@shadowen.org \
--cc=akpm@osdl.org \
--cc=andrea@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
--cc=nickpiggin@yahoo.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox