public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: James Pearson <james-p@moving-picture.com>,
	Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: Reducing inode cache usage on 2.4?
Date: Mon, 20 Dec 2004 18:54:09 +0100	[thread overview]
Message-ID: <20041220175409.GH4630@dualathlon.random> (raw)
In-Reply-To: <20041220150634.GA3113@logos.cnet>

On Mon, Dec 20, 2004 at 01:06:34PM -0200, Marcelo Tosatti wrote:
> The thing is right now we dont try to reclaim from icache/dcache _at all_ 
> if enough clean pagecache pages are found and reclaimed.
> 
> Its sounds unfair to me.

If most ram is in pagecache there's not much point to shrink the dcache.
The more ram goes into dcache/icache, the less ram will be in pagecache,
and the more likely we'll start shrinking dcache/icache. Also keep in
mind in a highmem machine the pagecache will be in highmemory and the
dcache/icache in lowmemory (on very very big boxes the lowmem_reserve
algorithm pratically splits the two in non-overkapping zones), so
especially on a big highmem machine shrinking dcache/icache during a
pagecache allocation (because this is what the workload is doing: only
pagecache allocations) is a worthless effort.

This is the best solution we have right now, but there have been several
discussions in the past on how to shrink dcache/icache. But if we want
to talk on how to change this, we should talk about 2.6/2.7 only IMHO.

> Why not? If we have a lot of them they will probably be hurting performace, which seems
> to be the case now.

The slowdown could be because the icache/dcache hash size is too small.
It signals collisions in the dcache/icache hashtable. 2.6 with bootmem
allocated hashes should be better. Optimizing 2.4 for performance if not
worth the risk IMHO. I would suggest to check if you can reproduce in
2.6, and fix it there, if it's still there.

> Following this logic any workload which generates pagecache and happen
> to, most times, have enough pagecache clean to be reclaimed should not
> reclaim the i/dcache's.  Which is not right.

This mostly happens for cache-polluting-workloads like in this testcase.
If the cache would be activated, there would be less pages in the
inactive list and you had a better chance to invoke the dcache/icache
shrinking.

  reply	other threads:[~2004-12-20 17:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-17 17:26 Reducing inode cache usage on 2.4? James Pearson
2004-12-17 15:12 ` Marcelo Tosatti
2004-12-17 21:52   ` Willy Tarreau
2004-12-18  0:32   ` James Pearson
2004-12-18  1:21     ` Andrew Morton
2004-12-18 11:02       ` Marcelo Tosatti
2004-12-20 13:47         ` James Pearson
2004-12-20 12:46           ` Marcelo Tosatti
2004-12-20 15:10             ` Andrea Arcangeli
2004-12-20 15:06               ` Marcelo Tosatti
2004-12-20 17:54                 ` Andrea Arcangeli [this message]
2004-12-20 15:43                   ` Marcelo Tosatti
2004-12-20 19:20       ` Andrea Arcangeli
2004-12-21 11:33         ` James Pearson
2004-12-21 13:22           ` Andrea Arcangeli
2004-12-21 13:59             ` James Pearson
2004-12-21 14:39               ` Andrea Arcangeli
2004-12-18 15:02     ` Marcelo Tosatti

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=20041220175409.GH4630@dualathlon.random \
    --to=andrea@suse.de \
    --cc=akpm@osdl.org \
    --cc=james-p@moving-picture.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo.tosatti@cyclades.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