lkml.org 
[lkml]   [2000]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site