On Tue, 6 Jun 2000, Andi Kleen wrote:
> On Tue, Jun 06, 2000 at 06:30:03AM -0700, Chris Mason wrote:
> > We need two things:
> >
> > 1) a way to reserve and release a pinned page count. This will allow a
> > pinned page high watermark so the journaled filesystems can plan nice
> > without pinning all the ram.
> >
> > 2) A memory pressure call back in the address space operations. This
> > really does seem more flexible than a call in struct super_operations.
>
> This would involve that the pages in the transaction are added
> to the global LRU (otherwise there would be no easy way to get
> at their transactions). Does that really make sense ? I would
> guess that putting very different things (normal write behind
> pages, write behind pages waiting for a transaction and high
> priority log pages) into the same LRU does not make sense.
I agree with this, it probably doesn't make much sense to put
pinned pages in the LRU queue, since there's no way to free
them anyway. The LRU queue should probably just contain freeable
pages.
OTOH, if we move to an active/inactive/scavenge list VM subsystem,
it may make sense to put the journaled FS pages on the active list
and exert pressure on the FS from there...
if (jfs_page(page)) {
page->mapping->sb->memory_pressure++;
if (page->mapping->sb->memory_pressure > cluster_pages)
page->mapping->sb->sync_pages();
}
Or something similarly simple to this ;)
> I was more thinking about something like:
>
> - Every journal maintains a pinned page counter per file system
> that is linked into a global list (that could be the super block
> or a separate structure). Using the address space operations for
> that seems to be overkill, because there are many of them (you
> probably want one per journal/fs, not one per inode)
>
> - Try_to_free_pages walks this structure (probably with an
> similar algorithm as the current swapper) and tells the journals
> to free some pages.
This would tie in nicely with the register_cache() function
proposed some weeks ago. This is probably the way to go with
the current VM subsystem, but somehow I don't think we'll want
to keep VM as it is today ;)
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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:25 EST