public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Rik van Riel <riel@conectiva.com.br>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	Hans Reiser <reiser@namesys.com>,
	Andreas Gruenbacher <agruen@suse.de>, Alan Cox <alan@redhat.com>,
	Marcelo Tosatti <marcelo@conectiva.com.br>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Caches that shrink automatically
Date: 04 Aug 2002 15:42:43 -0600	[thread overview]
Message-ID: <m1bs8is3l8.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.LNX.4.44L.0208041555500.23404-100000@imladris.surriel.com>

Rik van Riel <riel@conectiva.com.br> writes:

> On Sun, 4 Aug 2002, Linus Torvalds wrote:
> > On Sun, 4 Aug 2002, Rik van Riel wrote:
> > >
> > > Linus has indicated that he would like to have it page based,
> > > but implementation issues point towards letting the subcache
> > > manage its objects by itself ;)
> >
> > The two are not mutually incompatible.
> 
> > In particular, it is useless for the sub-caches to try to maintain their
> > own LRU lists and their own accessed bits. But that doesn't mean that
> > they can _act_ as if they updated their own accessed bits, while really
> > just telling the page-based thing that that page is active.
> 
> I'm not sure I agree with this.  For eg. the dcache you will want
> to reclaim the less used entries on a page even if there are a few
> very intensely used entries on that page.
> 
> This is because then new dcache allocations can come from the
> empty space on this page and the dcache doesn't have to grow in
> order to allocate new entries.
> 
> If we were to go fully page-based, it'd become impossible to evict
> dcache entries from any page with at least one heavily used entry
> and the dcache will use much more space than otherwise required.
> In reality it'd be even worse because we cannot evict any dcache
> entry which is pinned by eg. inodes or directory entries.
> 
> Please tell me if I've overlooked something, it would be nice if
> the page based scheme could work out after all ;)

Another angle worth taking into account is that for any data that
is purely cached, (that is not currently pinned by a user), it is
possible to compact the data.  With rmap is property even applies to
pinned page cache pages.

For cases where internal fragmentation is likely it may be worth
taking advantage of this property.

Eric

  parent reply	other threads:[~2002-08-04 21:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-04 11:08 [PATCH] Caches that shrink automatically Andreas Gruenbacher
2002-08-04 11:30 ` Hans Reiser
2002-08-04 13:11   ` Andreas Gruenbacher
2002-08-04 13:56     ` Rik van Riel
2002-08-04 18:31       ` Hans Reiser
2002-08-04 18:44         ` Rik van Riel
2002-08-04 18:50           ` Linus Torvalds
2002-08-04 18:59             ` Rik van Riel
2002-08-04 19:05               ` Linus Torvalds
2002-08-04 19:17                 ` Hans Reiser
2002-08-05  7:44                   ` Joshua MacDonald
2002-08-04 21:42               ` Eric W. Biederman [this message]
2002-08-04 18:29     ` Hans Reiser
2002-08-04 18:43 ` Linus Torvalds

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=m1bs8is3l8.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=agruen@suse.de \
    --cc=alan@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=reiser@namesys.com \
    --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