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/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:21 EST