From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andrea Arcangeli <andrea@novell.com>
Cc: "Martin J. Bligh" <mbligh@aracnet.com>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: PG_zero
Date: Tue, 02 Nov 2004 13:54:11 +1100 [thread overview]
Message-ID: <4186F6D3.6010909@yahoo.com.au> (raw)
In-Reply-To: <20041102022122.GJ3571@dualathlon.random>
Andrea Arcangeli wrote:
> On Mon, Nov 01, 2004 at 11:34:19PM +0100, Andrea Arcangeli wrote:
>
>>On Mon, Nov 01, 2004 at 10:03:56AM -0800, Martin J. Bligh wrote:
>>
>>>[..] it was to stop cold
>>>allocations from eating into hot pages [..]
>>
>>exactly, and I believe that hurts. bouncing on the global lock is going to
>>hurt more than preserving an hot page (at least on a 512-way). Plus the
>>cold page may very soon become hot too.
>
>
> I've read your reply via the web in some archive since my email is down
> right now (probably some upgrade is underway).
>
>
> with global I mean the buddy lock, which is global for all cpus.
>
Hmm... yeah they global, but also per-zone. And most of the
page activity will be coming from the node local CPUs hopefully.
I guess the exception could be things like ZONE_NORMAL for big
highmem systems, but I think we don't want to be doing too much
more to accomodate those dinosaurs nowadays.
> 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. 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 yeah. I'm still unconvinced that the cacheline is bouncing
all that much.. I'm sure some of the guys at SGI will have profiles
lying around for their bigger systems though.
> 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. I do
> believe the latter is several order of magnitude more severe issue.
> Hence I allow fallbacks both ways (I even allow fallback across the zero
> pages that carry more info than just an hot cache). Mainline doesn't
> allow any fallback at all instead and that's certainly wrong.
>
> BTW, please apply PG_zero-2-no-zerolist-reserve-1 on top of PG_zero-2
> too if you're going to run any bench (PG_zero-2 alone doesn't give
> zeropages to non-zero users and I don't like it that much even if it
> mirrors the quicklists better). And to make a second run to disable the
> idle clearing sysctl you can just write 0 into the last entry of the
> per_cpu_pages syctl.
>
> If you can run the bench with several cpus and with with mem=1G that
> will put into action other bugfixes as well.
>
>
>>Plus you should at least allow an hot allocation to eat into the cold
>>pages (which didn't happen IIRC).
>
>
> all I could see is that it doesn't fallback in 2.6.9, and that's fixed
> with the single list of course ;). Plus I provide hot-cold caching on
> the zero list too (zero list guarantees all pages have PG_zero set, but
> that's the only difference with the hot-cold list). cold info is
> retained in the zero list too so you can freely allocate with __GFP_ZERO
> and __GFP_COLD, or even __GFP_ZERO|__GFP_ONLY_ZERO|__GFP_COLD etc...
>
OK well I guess any changes are a matter for the numbers to decide,
speculation only gets one so far :)
(Great to see you're getting more time to work on 2.6 BTW).
next prev parent reply other threads:[~2004-11-02 3:03 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 ` Nick Piggin [this message]
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=4186F6D3.6010909@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=andrea@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
/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