From: Andrea Arcangeli <andrea@suse.de>
To: Rik van Riel <riel@conectiva.com.br>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dcache 2nd chance replacement
Date: Thu, 4 Jan 2001 17:18:07 +0100 [thread overview]
Message-ID: <20010104171807.B1507@athlon.random> (raw)
In-Reply-To: <20010104013201.B6256@athlon.random> <Pine.LNX.4.21.0101041255320.1188-100000@duckman.distro.conectiva>
In-Reply-To: <Pine.LNX.4.21.0101041255320.1188-100000@duckman.distro.conectiva>; from riel@conectiva.com.br on Thu, Jan 04, 2001 at 01:00:28PM -0200
On Thu, Jan 04, 2001 at 01:00:28PM -0200, Rik van Riel wrote:
> Other tasks tend not to stress the dcache like updatedb does,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> leading to the effect that updatedb can "flush out" the other
> cached values faster than the other processes reference them.
>
> This is something no amount of 2nd chance replacement or even
> aging can prevent.
Your arguments are senseless.
The dcache aging is mostly useful with _high_ VFS load like updatedb in
background. The logic is the same of the VM aging (ask yourself when the VM
aging is most useful: when there's high VM load, like a `cp /dev/zero .` in
background, the updatedb is the equivalent of `cp /dev/zero .` but for the
dcache). Without the aging the "referenced" cache would be thrown away as well
with the rest of the cache pollution, while with the aging the "referenced"
cache will have a chance to remain in cache. This is true for both VM cache and
dcache. The higher the load, the more times your working set would been thrown
away without the aging, so the higher improvement you get thanks to the aging.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2001-01-04 16:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-03 18:59 [PATCH] dcache 2nd chance replacement Rik van Riel
2001-01-03 19:05 ` Linus Torvalds
2001-01-03 19:11 ` Rik van Riel
2001-01-03 19:43 ` Andrea Arcangeli
2001-01-03 19:47 ` Rik van Riel
2001-01-03 21:12 ` Andrea Arcangeli
2001-01-03 23:09 ` Rik van Riel
2001-01-04 0:32 ` Andrea Arcangeli
2001-01-04 15:00 ` Rik van Riel
2001-01-04 16:18 ` Andrea Arcangeli [this message]
2001-01-04 16:23 ` Rik van Riel
2001-01-04 16:52 ` Andrea Arcangeli
2001-01-04 16:59 ` Rik van Riel
2001-01-04 17:35 ` Andrea Arcangeli
2001-01-04 17:36 ` Rik van Riel
2001-01-04 17:47 ` Alan Cox
2001-01-05 12:08 ` Chris Evans
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=20010104171807.B1507@athlon.random \
--to=andrea@suse.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
--cc=torvalds@transmeta.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