Re: journaling & VM (was: Re: reiserfs being part of the kernel: it'snot just the code)

quoted

quoted

quoted

quoted

"sct" == Stephen C Tweedie [off-list ref] writes:

sct> Hi,
sct> On Wed, Jun 07, 2000 at 11:40:47PM +0200, Juan J. Quintela wrote:

quoted

Hi
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?

sct> Because even if the information about which page is least recently
sct> used doesn't help you, the information about which filesystems are
sct> least active _does_ help.

ok, I see what is your point here.

quoted

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.

sct> No, Rik was explicitly allowing the per-fs flush functions to 
sct> indicate how much progress was being made, to avoid this.

That didn't avoid this, the next time that you scan that list, the
page from the same filesystem will appear, and you will flush pages
from that filesystem.  And so on.

quoted

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.

sct> We _have_ to have separate mechanisms for page cleaning and for page
sct> reclaim.  Interrupt load requires that we free pages rapidly on 
sct> demand, regardless of whether the page cleaner is stalled in the 
sct> middle of a write operation or not.

I agree on that also, I have offered my help to Rik to implement
that.  That means that I also like that idea.

[Rest of the mail deleted, I also agree on that].

Thanks a lot for your comments in this topic.  I apreciate a lot the
comments of everybody.

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/