Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Fri, 11 Feb 2000 15:48:34 +0000 (GMT) | Subject | Re: Linux Status For 2.3.x: v 2.3.43 |
| |
Hi,
On Thu, 10 Feb 2000 20:41:38 -0500 (EST), Alexander Viro <viro@math.psu.edu> said:
>> Done >> ---- >> SCSI needs allocate/free functions to fix the gdth stuff >> Fixing scsi blocking and cleanups >> PAE36 failures (? - ok now )
> Address_space methods patch done. Makes truncate and memory-pressure stuff > immediately doable. Stephen, could we discuss the details of > memory-pressure stuff?
Yep, although some of it may end up being a 2.5 job I expect.
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.
* 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).
* 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.
--Stephen
- 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/
| |