On Fri, 11 Feb 2000, Stephen C. Tweedie wrote:
> There are basically three things we need to deal with.
>
> * Freeing memory.
>
> The simple one. An application wants more memory, so we need to throw
> something out of cache.
Probable point where we call it being shrink_mmap(). Other candidates?
> * Write throttling.
>
> There needs to be a way of detecting when we have too many dirty pages
> in memory so that we can stall new write activity while we go about
> flushing some old writes to disk. Right now we have this for the
> buffer cache but we can't provide similar levels of write throttling
> for filesystems which use the page cache exclusively (ie. without
> using the buffer dirty list).
Ahem... OK, we can put the counter for dirty pages and put them into the
head of the ->pages.
> * Pinned memory thresholds.
>
> Some filesystems create pages which simply cannot be flushed to disk
> on demand. For example, a journaled filesystem cannot necessarily
> flush things out until the transaction in progress commits, so we need
> to guarantee that the transaction can get enough new memory to
> commit. Similarly, filesystems which perform allocate-on-write cannot
> flush their dirty buffers out to disk without first performing other
> disk IOs to complete the allocation.
>
> There _must_ be a hard, system-wide limit on such pinned pages, so
> that we can guarantee that when we do want to flush pinned pages,
> there is enough unpinned memory available to the page stealer to allow
> the fs transactions to complete and the pinned pages to be released.
>
> This implies a global count of pinned pages *and* of reservations for
> future pinned pages; and a mechanism for calling back into filesystems
> to start unpinning old pages once the threshold is reached.
Ouch. Now, that may turn out nasty - deadlocks are fun...
OK, let's do the simple stuff first - are you OK with per-address_space
->shrink_mapping() being called from shrink_mmap()?
-
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 Feb 23 2000 - 21:00:17 EST