Messages in this thread |  | | | Date | Thu, 17 Feb 2000 02:36:03 -0500 (EST) | | From | Alexander Viro <> | | Subject | Re: Linux Status For 2.3.x: v 2.3.43 |
| |
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/
|  |