From: Andrew Morton <akpm@osdl.org>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: andrea@novell.com, nickpiggin@yahoo.com.au, linux-kernel@vger.kernel.org
Subject: Re: PG_zero
Date: Tue, 2 Nov 2004 13:09:10 -0800 [thread overview]
Message-ID: <20041102130910.3e779d32.akpm@osdl.org> (raw)
In-Reply-To: <11900000.1099410137@[10.10.2.4]>
"Martin J. Bligh" <mbligh@aracnet.com> wrote:
>
> > The idea that the quicklist is meant to take the lock once every X pages
> > is limiting. The object is to never ever have to enter the buddy, not
> > just to "buffer" allocations.
>
> That'd be nicer, yes.
>
> > The two separated cold/hot lists prevents that. As far as there's a single
> > page available we should use it since bouncing the cacheline is very costly.
>
> Well, it doesn't really prevent it ... it used to work, I think. However,
> the current code appears to be broken - what it's meant to do is refill
> the hot list from the cold list if the hot list was completely empty.
> I could've sworn it used to do that, but no matter
We discussed it, but iirc we worked out that it wouldn't have any useful
effect on the frequency at which we take the buddy lock.
It adds more code and it adds special knowledge of hotness and coldness to
the core page allocator. The intention was that the argument called `cold'
could be renamed to `pcp_index' or whatever so that we could add more head
arrays in the future. For known-to-be-zero pages.
> ... I think we just
> need to fix up the bit in buffered_rmqueue() here:
>
> if (pcp->count <= pcp->low)
> pcp->count += rmqueue_bulk(zone, 0, pcp->batch, &pcp->list);
>
> To say something more like:
>
> if (pcp->count <= pcp->low && !cold)
> <shift some pages from cold to hot>
> if (pcp->count <= pcp->low)
> pcp->count += rmqueue_bulk(zone, 0, pcp->batch, &pcp->list);
>
> Though I'm less than convinced in retrospect that there was any point in
> having low watermarks, rather than running it down to zero. Andrew, can
> you recall why we did that?
Nope.
> > It's really a question if you believe the cache effects are going to be
> > more significant than the cacheline bouncing on the zone lock.
>
> Exactly. The disadvantage of the single list is that cold allocs can steal
> hot pages, which we believe are precious, and as CPUs get faster, will only
> get more so (insert McKenney's bog roll here).
The cold pages are mainly intended to be the pages which will be placed
under DMA transfers. We should never return hot pages in response for a
request for a cold page.
next prev parent reply other threads:[~2004-11-02 21:05 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 ` PG_zero Andy Whitcroft
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 ` Andrew Morton [this message]
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=20041102130910.3e779d32.akpm@osdl.org \
--to=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
Powered by JetHome