[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.022 / U:41.416 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site