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 ?
Once shrink_mmap (or similar function) uses the call back from any page
in the FS, I can use that to start reclaiming.
> 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 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.
>
Ok, I see where you are going. But, what we want to do is add
functionality to allow a system-wide pinned page limit, and a fair way to
enforce it. Most journaled filesystems already reserve blocks at the
start of the transactions, and can wait for that reserveration to finish,
so changing the journal end is really easy.
So, the plan was to code
int reserve_pinned(int pages) ;
int reserve_pinned_wait(int pages) ;
int release_pinned(int pages) ;
int do_recover_reservations( undecided ) ;
Where reserve_pinned just returned an error when more pages were not
available, and reserve_pinned_wait called do_recover_reservations, which
kicked off the memory pressure system, and put people on a wait queue
until more pinning was allowed. The idea was to also allow shrink_mmap
(or similar func) to kick off its own recover of pinned pages.
I'm not partial to how the actually memory pressure subsystem works, but I
do like the idea of putting it in the address space operations. It just
seems right, memory pressure goes against adress spaces.
Plus, it allows more flexibility later on...the log really should be an
address space of its own, and the pressure should be applied against the
log, not the FS. Think of multiple filesystems to a log, or multiple
logs in a filesystem. Yes, these are ideas for 2.5 ;-)
-chris
-
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