From: "Juan J. Quintela" <quintela@fi.udc.es>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Rik van Riel <riel@conectiva.com.br>,
Hans Reiser <hans@reiser.to>, 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: 07 Jun 2000 23:40:47 +0200 [thread overview]
Message-ID: <yttvgzlcgps.fsf@serpe.mitica> (raw)
In-Reply-To: "Stephen C. Tweedie"'s message of "Wed, 7 Jun 2000 22:24:21 +0100"
>>>>> "stephen" == Stephen C Tweedie <sct@redhat.com> writes:
Hi
stephen> All transactional filesystems will have ordering constraints which
stephen> the core VM cannot know about. In that case, the filesystem may
stephen> simply have no choice about cleaning and unpinning pages in a given
stephen> order. For actually removing a page from memory, evicting precisely
stephen> the right page is far more important, but for writeback, it's
stephen> controlling the amount of dirty/pinned data from the various different
stephen> sources which counts.
Fair enough, don't put pinned pages in the LRU, *why* do you want put
pages in the LRU if you can't freed it when the LRU told it: free that
page? Ok. New example. You have the 10 (put here any number) older
pages in the LRU. That pages are pinned in memory, i.e. you can't
remove them. You will call the ->flush() function in each of them
(put it any name for the method). Now, the same fs has a lot of new
pages in the LRU that are being used actively, but are not pinned in
this precise instant. Each time that we call the flush method, we
will free some dirty pages, not the pinned ones, evidently. We will
call that flush function 10 times consecutively. Posibly we will
flush all the pages from the cache for that fs, and for not good
reason. The only reason was that it was the 10 oldest pages in the
LRU, nothing else. Yes, I know that this is a pathological case, but
I think that we should work ok in that case also.
I will be also very happy with only one place where doing the aging,
cleaning, ... of _all_ the pages, but for that place we need a policy,
and that policy _must_ be honored (almost) always or it doesn't make
sense and we will arrive to unstable/unfair situations.
I am working just now in a patch that will allow pages to be defered
the write of mmaped pages from the swap_out function to shrink_mmap
time. The same that we do with swap pages actually, but for fs pages
mmaped in processes. That would help that. But note that in this
case, I put in the LRU pages that can be freed. I can't understand
putting pages that are not freeable. I told that to show that I am
supportive of the idea of only one LRU queue (or multiqueue, that is
the same).
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
--
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 21:40 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 ` journaling & VM (was: Re: reiserfs being part of the kernel:it'snot " Hans Reiser
2000-06-07 13:40 ` journaling & VM (was: Re: reiserfs being part of the kernel: it'snot " 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 [this message]
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=yttvgzlcgps.fsf@serpe.mitica \
--to=quintela@fi.udc.es \
--cc=ahu@ds9a.nl \
--cc=hans@reiser.to \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=mason@suse.com \
--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