All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Andrea Arcangeli <andrea@suse.de>
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 13:43:34 -0200	[thread overview]
Message-ID: <20041220154333.GC3345@logos.cnet> (raw)
In-Reply-To: <20041220175409.GH4630@dualathlon.random>

On Mon, Dec 20, 2004 at 06:54:09PM +0100, Andrea Arcangeli wrote:
> 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.

OK I buy your arguments I'll revert Andrew's patch.

  reply	other threads:[~2004-12-20 18:02 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
2004-12-20 15:43                   ` Marcelo Tosatti [this message]
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=20041220154333.GC3345@logos.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=akpm@osdl.org \
    --cc=andrea@suse.de \
    --cc=james-p@moving-picture.com \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.