mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Andrea Arcangeli <andrea@novell.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
	Andrew Morton <akpm@digeo.com>,
	linux-kernel@vger.kernel.org
Subject: Re: PG_zero
Date: Tue, 02 Nov 2004 07:42:18 -0800	[thread overview]
Message-ID: <11900000.1099410137@[10.10.2.4]> (raw)
In-Reply-To: <20041102022122.GJ3571@dualathlon.random>

> 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 ... 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?

> 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).

> 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.

Mmmm. Are you actually seeing lock contention on the buddy allocator on
a real benchmark? I haven't seen it since the advent of hot/cold pages.
Remember it's not global at all on the larger systems, since they're NUMA.
 
> 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...

Mmmm. I'm still very worried this'll exhaust ZONE_NORMAL on highmem systems,
and keep remote pages around instead of returning them to their home node
on NUMA systems. Not sure that's really what we want, even if we gain a
little in spinlock and immediate cache cost. Nor will it be easy to measure
since it'll only do anything under memory pressure, and the perf there is
notoriously unstable for measurement.

M.

  parent reply	other threads:[~2004-11-02 15:52 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         ` Martin J. Bligh [this message]
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='11900000.1099410137@[10.10.2.4]' \
    --to=mbligh@aracnet.com \
    --cc=akpm@digeo.com \
    --cc=andrea@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    --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

all inboxes | Powered by JetHome®