[lkml]   [2010]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH 0/6] Do not call ->writepage[s] from direct reclaim and use a_ops->writepages() where possible
    On Tue, Jun 08, 2010 at 05:08:11AM -0400, Christoph Hellwig wrote:
    > On Tue, Jun 08, 2010 at 10:02:19AM +0100, Mel Gorman wrote:
    > > seeky patterns. The second is that direct reclaim calling the filesystem
    > > splices two potentially deep call paths together and potentially overflows
    > > the stack on complex storage or filesystems. This series is an early draft
    > > at tackling both of these problems and is in three stages.
    > Btw, one more thing came up when I discussed the issue again with Dave
    > recently:
    > - we also need to care about ->releasepage. At least for XFS it
    > can end up in the same deep allocator chain as ->writepage because
    > it does all the extent state conversions, even if it doesn't
    > start I/O.


    > I haven't managed yet to decode the ext4/btrfs codepaths
    > for ->releasepage yet to figure out how they release a page that
    > covers a delayed allocated or unwritten range.

    If ext4/btrfs are also very deep call-chains and this series is going more
    or less the right direction, then avoiding calling ->releasepage from direct
    reclaim is one, somewhat unfortunate, option. The second is to avoid it on
    a per-filesystem basis for direct reclaim using PF_MEMALLOC to detect
    reclaimers and PF_KSWAPD to tell the difference between direct
    reclaimers and kswapd.

    Either way, these pages could be treated similar to dirty pages on the
    dirty_pages list.

    Mel Gorman
    Part-time Phd Student Linux Technology Center
    University of Limerick IBM Dublin Software Lab

     \ /
      Last update: 2010-06-08 11:31    [W:0.022 / U:41.468 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site