From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754470Ab0BXDMK (ORCPT ); Tue, 23 Feb 2010 22:12:10 -0500 Received: from mga11.intel.com ([192.55.52.93]:10294 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754295Ab0BXDMH (ORCPT ); Tue, 23 Feb 2010 22:12:07 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.49,529,1262592000"; d="scan'208";a="775369720" Message-Id: <20100224031055.738182009@intel.com> User-Agent: quilt/0.48-1 Date: Wed, 24 Feb 2010 11:10:16 +0800 From: Wu Fengguang To: Andrew Morton CC: Jens Axboe , Nick Piggin , Wu Fengguang CC: Chris Mason CC: Peter Zijlstra CC: Clemens Ladisch CC: Olivier Galibert cc: Vivek Goyal cc: Christian Ehrhardt cc: Matt Mackall cc: Linux Memory Management List CC: Cc: LKML Subject: [PATCH 15/15] readahead: pagecache context based mmap read-around References: <20100224031001.026464755@intel.com> Content-Disposition: inline; filename=readahead-mmap-around-context.patch Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Do mmap read-around when there are cached pages in the nearby 256KB (covered by one radix tree node). There is a failure case though: for a sequence of page faults at page index 64*i+1, i=1,2,3,..., this heuristic will keep doing pointless read-arounds. Hopefully the pattern won't appear in real workloads. Note that the readahead heuristic has similiar failure case. CC: Nick Piggin Signed-off-by: Wu Fengguang --- mm/filemap.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) --- linux.orig/mm/filemap.c 2010-02-23 13:20:39.000000000 +0800 +++ linux/mm/filemap.c 2010-02-23 13:22:36.000000000 +0800 @@ -1421,11 +1421,17 @@ static void do_sync_mmap_readahead(struc /* - * Do we miss much more than hit in this file? If so, - * stop bothering with read-ahead. It will only hurt. + * Do we miss much more than hit in this file? If so, stop bothering + * with read-around, unless some nearby pages were accessed recently. */ - if (ra_mmap_miss_inc(ra) > MMAP_LOTSAMISS) - return; + if (ra_mmap_miss_inc(ra) > MMAP_LOTSAMISS) { + struct radix_tree_node *node; + rcu_read_lock(); + node = radix_tree_lookup_leaf_node(&mapping->page_tree, offset); + rcu_read_unlock(); + if (!node) + return; + } /* * mmap read-around From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wu Fengguang Subject: [PATCH 15/15] readahead: pagecache context based mmap read-around Date: Wed, 24 Feb 2010 11:10:16 +0800 Message-ID: <20100224031055.738182009@intel.com> References: <20100224031001.026464755@intel.com> Cc: Jens Axboe , Nick Piggin , Wu Fengguang To: Andrew Morton Return-path: CC: Chris Mason CC: Peter Zijlstra CC: Clemens Ladisch CC: Olivier Galibert cc: Vivek Goyal cc: Christian Ehrhardt cc: Matt Mackall cc: Linux Memory Management List CC: Cc: LKML Content-Disposition: inline; filename=readahead-mmap-around-context.patch Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org Do mmap read-around when there are cached pages in the nearby 256KB (covered by one radix tree node). There is a failure case though: for a sequence of page faults at page index 64*i+1, i=1,2,3,..., this heuristic will keep doing pointless read-arounds. Hopefully the pattern won't appear in real workloads. Note that the readahead heuristic has similiar failure case. CC: Nick Piggin Signed-off-by: Wu Fengguang --- mm/filemap.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) --- linux.orig/mm/filemap.c 2010-02-23 13:20:39.000000000 +0800 +++ linux/mm/filemap.c 2010-02-23 13:22:36.000000000 +0800 @@ -1421,11 +1421,17 @@ static void do_sync_mmap_readahead(struc /* - * Do we miss much more than hit in this file? If so, - * stop bothering with read-ahead. It will only hurt. + * Do we miss much more than hit in this file? If so, stop bothering + * with read-around, unless some nearby pages were accessed recently. */ - if (ra_mmap_miss_inc(ra) > MMAP_LOTSAMISS) - return; + if (ra_mmap_miss_inc(ra) > MMAP_LOTSAMISS) { + struct radix_tree_node *node; + rcu_read_lock(); + node = radix_tree_lookup_leaf_node(&mapping->page_tree, offset); + rcu_read_unlock(); + if (!node) + return; + } /* * mmap read-around -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wu Fengguang Subject: [PATCH 15/15] readahead: pagecache context based mmap read-around Date: Wed, 24 Feb 2010 11:10:16 +0800 Message-ID: <20100224031055.738182009@intel.com> References: <20100224031001.026464755@intel.com> Return-path: Received: from kanga.kvack.org ([205.233.56.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nk7fg-0006Dn-8R for glkm-linux-mm-2@m.gmane.org; Wed, 24 Feb 2010 04:12:20 +0100 Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3]) by kanga.kvack.org (Postfix) with SMTP id A69D26B0078 for ; Tue, 23 Feb 2010 22:12:07 -0500 (EST) Content-Disposition: inline; filename=readahead-mmap-around-context.patch Sender: owner-linux-mm@kvack.org To: Andrew Morton Cc: Jens Axboe , Nick Piggin , Wu Fengguang , Chris Mason , Peter Zijlstra , Clemens Ladisch , Olivier Galibert , Vivek Goyal , Christian Ehrhardt , Matt Mackall , Linux Memory Management List , linux-fsdevel@vger.kernel.org, LKML List-Id: linux-mm.kvack.org Do mmap read-around when there are cached pages in the nearby 256KB (covered by one radix tree node). There is a failure case though: for a sequence of page faults at page index 64*i+1, i=1,2,3,..., this heuristic will keep doing pointless read-arounds. Hopefully the pattern won't appear in real workloads. Note that the readahead heuristic has similiar failure case. CC: Nick Piggin Signed-off-by: Wu Fengguang --- mm/filemap.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) --- linux.orig/mm/filemap.c 2010-02-23 13:20:39.000000000 +0800 +++ linux/mm/filemap.c 2010-02-23 13:22:36.000000000 +0800 @@ -1421,11 +1421,17 @@ static void do_sync_mmap_readahead(struc /* - * Do we miss much more than hit in this file? If so, - * stop bothering with read-ahead. It will only hurt. + * Do we miss much more than hit in this file? If so, stop bothering + * with read-around, unless some nearby pages were accessed recently. */ - if (ra_mmap_miss_inc(ra) > MMAP_LOTSAMISS) - return; + if (ra_mmap_miss_inc(ra) > MMAP_LOTSAMISS) { + struct radix_tree_node *node; + rcu_read_lock(); + node = radix_tree_lookup_leaf_node(&mapping->page_tree, offset); + rcu_read_unlock(); + if (!node) + return; + } /* * mmap read-around -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org