From: Hans Reiser <hans@reiser.to>
To: Rik van Riel <riel@conectiva.com.br>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
"Quintela Carreira Juan J." <quintela@fi.udc.es>,
bert hubert <ahu@ds9a.nl>,
linux-kernel@vger.rutgers.edu, Chris Mason <mason@suse.com>,
linux-mm@kvack.org,
Alexander Zarochentcev <zam@odintsovo.comcor.ru>
Subject: Re: journaling & VM (was: Re: reiserfs being part of the kernel:it'snot just the code)
Date: Wed, 07 Jun 2000 12:02:48 -0700 [thread overview]
Message-ID: <393E9C58.9FE2A0E0@reiser.to> (raw)
In-Reply-To: <Pine.LNX.4.21.0006071018320.14304-100000@duckman.distro.conectiva>
Rik van Riel wrote:
>
> On Wed, 7 Jun 2000, Stephen C. Tweedie wrote:
> > On Tue, Jun 06, 2000 at 08:45:08PM -0700, Hans Reiser wrote:
> > > >
> > > > This is the reason because of what I think that one operation in the
> > > > address space makes no sense. No sense because it can't be called
> > > > from the page.
> > >
> > > What do you think of my argument that each of the subcaches should register
> > > currently_consuming counters which are the number of pages that subcache
> > > currently takes up in memory,
> >
> > There is no need for subcaches at all if all of the pages can be
> > represented on the page cache LRU lists. That would certainly
> > make balancing between caches easier.
>
> Wouldn't this mean we could end up with an LRU cache full of
> unfreeable pages?
>
> Then we would scan the LRU cache and apply pressure on all of
> the filesystems, but then the filesystem could decide it wants
> to flush *other* pages from the ones we have on the LRU queue.
And we intend to do exactly that with allocate on flush. Eventually we will
even repack on flush.
>
> This could get particularly nasty when we have a VM with
> active / inactive / scavenge lists... (like what I'm working
> on now)
>
> Then again, if the filesystem knows which pages we want to
> push, it could base the order in which it is going to flush
> its blocks on that memory pressure. Then your scheme will
> undoubtedly be the more robust one.
>
> Question is, are the filesystems ready to play this game?
Yes, we are eager to play, but you do intend that the filesystem will be
pressured to age not flush, yes?
That is, if aging causes something to get flushed, it gets flushed, but if not
then not.
The filesystems should get passed some notion of how much of their cache to age
so that you MM guys can have fun varying this.
You might want us to return how much got scheduled for flushing as a result of
the aging, that way you know when to stop pressuring caches.
>
> regards,
>
> Rik
> --
> The Internet is not a network of computers. It is a network
> of people. That is its real strength.
>
> Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies
> http://www.conectiva.com/ http://www.surriel.com/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next prev parent reply other threads:[~2000-06-07 19:02 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.10.10006060811120.15888-100000@dax.joh.cam.ac.uk>
[not found] ` <393CA40C.648D3261@reiser.to>
[not found] ` <20000606114851.A30672@home.ds9a.nl>
[not found] ` <393CBBB8.554A0D2A@reiser.to>
[not found] ` <20000606172606.I25794@redhat.com>
[not found] ` <393D37D1.1BC61DC3@reiser.to>
[not found] ` <20000606205447.T23701@redhat.com>
2000-06-06 23:06 ` journaling & VM (was: Re: reiserfs being part of the kernel: it's not " Rik van Riel
2000-06-07 1:19 ` journaling & VM (was: Re: reiserfs being part of the kernel: it'snot " Hans Reiser
2000-06-07 1:46 ` Quintela Carreira Juan J.
2000-06-07 3:45 ` Hans Reiser
2000-06-07 11:15 ` Stephen C. Tweedie
2000-06-07 13:23 ` Rik van Riel
2000-06-07 13:41 ` Stephen C. Tweedie
2000-06-07 14:27 ` Rik van Riel
2000-06-07 14:46 ` Stephen C. Tweedie
2000-06-07 14:51 ` bert hubert
2000-06-07 15:20 ` Quintela Carreira Juan J.
2000-06-07 15:35 ` Stephen C. Tweedie
2000-06-07 15:41 ` Rik van Riel
2000-06-07 15:44 ` Juan J. Quintela
2000-06-07 17:10 ` Jeff V. Merkey
2000-06-07 17:14 ` Stephen C. Tweedie
2000-06-07 17:21 ` Jeff V. Merkey
2000-06-07 20:16 ` Hans Reiser
2000-06-07 21:20 ` Rik van Riel
2000-06-07 21:52 ` journaling & VM Hans Reiser
2000-06-07 22:11 ` James Sutherland
2000-06-07 22:29 ` Rik van Riel
2000-06-08 1:11 ` Neil Schemenauer
2000-06-08 1:29 ` Rik van Riel
2000-06-07 20:16 ` journaling & VM (was: Re: reiserfs being part of the kernel: it'snot just the code) Hans Reiser
2000-06-07 20:54 ` Stephen C. Tweedie
2000-06-07 21:29 ` Hans Reiser
2000-06-07 21:31 ` Rik van Riel
2000-06-07 21:33 ` Stephen C. Tweedie
2000-06-07 22:20 ` journaling & VM Hans Reiser
2000-06-07 21:50 ` journaling & VM (was: Re: reiserfs being part of the kernel: it'snot just the code) Juan J. Quintela
2000-06-07 19:02 ` Hans Reiser [this message]
2000-06-07 13:40 ` Chris Mason
2000-06-07 13:47 ` Stephen C. Tweedie
2000-06-07 11:12 ` Stephen C. Tweedie
2000-06-07 16:35 ` journaling & VM John Fremlin
2000-06-07 17:11 ` Stephen C. Tweedie
[not found] ` <20000608114435.A15433@uni-koblenz.de>
2000-06-08 21:29 ` Stephen C. Tweedie
2000-06-09 11:53 ` Ralf Baechle
2000-06-07 17:48 ` journaling & VM (was: Re: reiserfs being part of the kernel: it'snot just the code) Hans Reiser
2000-06-07 18:01 ` Rik van Riel
2000-06-07 19:58 ` Stephen C. Tweedie
2000-06-07 20:56 ` Juan J. Quintela
2000-06-07 21:14 ` Rik van Riel
2000-06-07 21:24 ` Stephen C. Tweedie
2000-06-07 21:40 ` Juan J. Quintela
2000-06-07 21:49 ` Stephen C. Tweedie
2000-06-07 22:00 ` Juan J. Quintela
2000-06-07 22:22 ` Manfred Spraul
2000-06-09 15:08 ` Rik van Riel
2000-06-09 16:52 ` Manfred Spraul
2000-06-09 17:23 ` Rik van Riel
2000-06-09 18:26 ` journaling & VM (was: Re: reiserfs being part of the kernel:it'snot " Manfred Spraul
2000-06-07 22:28 ` journaling & VM (was: Re: reiserfs being part of the kernel: it'snot " Hans Reiser
2000-06-07 10:10 ` journaling & VM (was: Re: reiserfs being part of the kernel: it's not " Stephen C. Tweedie
[not found] ` <393DACC8.5DB60A81@reiser.to>
2000-06-07 11:00 ` reiserfs being part of the kernel: it's not just the code Stephen C. Tweedie
2000-06-07 17:11 ` Rik van Riel
2000-06-07 17:13 ` Stephen C. Tweedie
2000-06-07 17:46 ` Hans Reiser
2000-06-07 19:53 ` Stephen C. Tweedie
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=393E9C58.9FE2A0E0@reiser.to \
--to=hans@reiser.to \
--cc=ahu@ds9a.nl \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=mason@suse.com \
--cc=quintela@fi.udc.es \
--cc=riel@conectiva.com.br \
--cc=sct@redhat.com \
--cc=zam@odintsovo.comcor.ru \
/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