From: Andrea Arcangeli <andrea@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: marcelo.tosatti@cyclades.com, j-nomura@ce.jp.nec.com,
linux-kernel@vger.kernel.org, riel@redhat.com, torvalds@osdl.org
Subject: Re: [2.4] heavy-load under swap space shortage
Date: Mon, 15 Mar 2004 01:14:00 +0100 [thread overview]
Message-ID: <20040315001400.GX30940@dualathlon.random> (raw)
In-Reply-To: <20040314152253.05c58ecc.akpm@osdl.org>
On Sun, Mar 14, 2004 at 03:22:53PM -0800, Andrew Morton wrote:
> Andrea Arcangeli <andrea@suse.de> wrote:
> >
> > >
> > > Having a magic knob is a weak solution: the majority of people who are
> > > affected by this problem won't know to turn it on.
> >
> > that's why I turned it _on_ by default in my tree ;)
>
> So maybe Marcelo should apply this patch, and also turn it on by default.
yes, I would suggest so. If anybody can find any swap-regression on
small UP machines then reporting to us on l-k will be welcome. So far
nobody could notice any swap difference at swap regime AFIK, and the
improvement for the fast path is dramatic on the big smp boxes.
> > There are workloads where adding anonymous pages to the lru is
> > suboptimal for both the vm (cache shrinking) and the fast path too
> > (lru_cache_add), not sure how 2.6 optimizes those bits, since with 2.6
> > you're forced to add those pages to the lru somehow and that implies
> > some form of locking.
>
> Basically a bunch of tweeaks:
>
> - Per-zone lru locks (which implicitly made them per-node)
the 16-ways weren't numa, and these days 16-ways HT (8-ways phys) are
not so uncommon anymore.
>
> - Adding/removing sixteen pages for one taking of the lock.
>
> - Making the lock irq-safe (it had to be done for other reasons, but
> reduced contention by 30% on 4-way due to not having a CPU wander off to
> service an interrupt while holding a critical lock).
>
> - In page reclaim, snip 32 pages off the lru completely and drop the
> lock while we go off and process them.
sounds good, thanks.
I don't see other ways to optimize it (and I never enjoyed too much the
per-zone lru since it has some downside too with a worst case on 2G
systems). peraphs a further optimization could be a transient per-cpu
lru refiled only by the page reclaim (so absolutely lazy while lots of
ram is free), but maybe that's already what you're doing when you say
"Adding/removing sixteen pages for one taking of the lock". Though the
fact you say "sixteen pages" sounds like it's not as lazy as it could
be.
next prev parent reply other threads:[~2004-03-15 0:13 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-02 10:12 j-nomura
2004-02-02 13:29 ` Hugh Dickins
2004-02-03 7:53 ` j-nomura
2004-02-03 17:19 ` Hugh Dickins
2004-02-04 11:40 ` j-nomura
2004-02-05 18:42 ` Hugh Dickins
2004-02-06 9:03 ` j-nomura
2004-03-10 10:57 ` j-nomura
2004-03-14 19:47 ` Marcelo Tosatti
2004-03-14 19:54 ` Rik van Riel
2004-03-14 20:15 ` Andrew Morton
[not found] ` <20040314230138.GV30940@dualathlon.random>
2004-03-14 23:22 ` Andrew Morton
2004-03-15 0:14 ` Andrea Arcangeli [this message]
2004-03-15 4:38 ` Nick Piggin
2004-03-15 11:49 ` Andrea Arcangeli
2004-03-15 13:23 ` Rik van Riel
2004-03-15 14:37 ` Nick Piggin
2004-03-15 14:50 ` Andrea Arcangeli
2004-03-15 18:35 ` Andrew Morton
2004-03-15 18:51 ` Andrea Arcangeli
2004-03-15 19:02 ` Andrew Morton
2004-03-15 21:55 ` Andrea Arcangeli
2004-03-15 22:05 ` Nick Piggin
2004-03-15 22:24 ` Andrea Arcangeli
2004-03-15 22:41 ` Nick Piggin
2004-03-15 22:44 ` Andrea Arcangeli
2004-03-15 22:41 ` Rik van Riel
2004-03-15 23:32 ` Andrea Arcangeli
2004-03-16 6:27 ` Nick Piggin
2004-03-16 7:25 ` Marcelo Tosatti
2004-03-16 6:31 ` Marcelo Tosatti
2004-03-16 13:47 ` Andrea Arcangeli
2004-03-16 16:59 ` Marcelo Tosatti
2004-11-22 15:01 ` Lazily add anonymous pages to LRU on v2.4? was " Marcelo Tosatti
2004-11-22 19:49 ` Andrea Arcangeli
2004-11-22 15:58 ` Marcelo Tosatti
2004-05-26 12:41 ` Marcelo Tosatti
2004-05-26 18:24 ` Marc-Christian Petersen
2004-05-27 11:16 ` Marcelo Tosatti
2004-05-26 19:06 ` Hugh Dickins
2004-05-26 22:23 ` Andrea Arcangeli
2004-05-28 2:55 ` j-nomura
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=20040315001400.GX30940@dualathlon.random \
--to=andrea@suse.de \
--cc=akpm@osdl.org \
--cc=j-nomura@ce.jp.nec.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.tosatti@cyclades.com \
--cc=riel@redhat.com \
--cc=torvalds@osdl.org \
/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®