[lkml]   [2000]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:56    [W:0.072 / U:22.480 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site