Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761126AbZDHCan (ORCPT ); Tue, 7 Apr 2009 22:30:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755090AbZDHCac (ORCPT ); Tue, 7 Apr 2009 22:30:32 -0400 Received: from mga14.intel.com ([143.182.124.37]:44115 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753706AbZDHCab (ORCPT ); Tue, 7 Apr 2009 22:30:31 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.39,341,1235980800"; d="scan'208";a="129064453" Date: Wed, 8 Apr 2009 10:29:55 +0800 From: Wu Fengguang To: Ying Han Cc: Andrew Morton , LKML , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" Subject: Re: [PATCH 03/14] mm: remove FAULT_FLAG_RETRY dead code Message-ID: <20090408022955.GA15993@localhost> References: <20090407071729.233579162@intel.com> <20090407072133.053995305@intel.com> <604427e00904071303g1d092eabp59fca0713ddacf82@mail.gmail.com> <20090407232700.GB5607@localhost> <604427e00904071817n767122byb439043e8a228011@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <604427e00904071817n767122byb439043e8a228011@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3958 Lines: 85 Hi Ying Han, On Wed, Apr 08, 2009 at 09:17:26AM +0800, Ying Han wrote: > On Tue, Apr 7, 2009 at 4:27 PM, Wu Fengguang wrote: > > On Wed, Apr 08, 2009 at 04:03:36AM +0800, Ying Han wrote: > >> On Tue, Apr 7, 2009 at 12:17 AM, Wu Fengguang wrote: > >> > Cc: Ying Han > >> > Signed-off-by: Wu Fengguang > >> > --- > >> > mm/memory.c | 4 +--- > >> > 1 file changed, 1 insertion(+), 3 deletions(-) > >> > > >> > --- mm.orig/mm/memory.c > >> > +++ mm/mm/memory.c > >> > @@ -2766,10 +2766,8 @@ static int do_linear_fault(struct mm_str > >> > { > >> > pgoff_t pgoff = (((address & PAGE_MASK) > >> > - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff; > >> > - int write = write_access & ~FAULT_FLAG_RETRY; > >> > - unsigned int flags = (write ? FAULT_FLAG_WRITE : 0); > >> > + unsigned int flags = (write_access ? FAULT_FLAG_WRITE : 0); > >> > > >> > - flags |= (write_access & FAULT_FLAG_RETRY); > >> > pte_unmap(page_table); > >> > return __do_fault(mm, vma, address, pmd, pgoff, flags, orig_pte); > >> > } > >> So, we got rid of FAULT_FLAG_RETRY flag? > > > > Seems yes for the current mm tree, see the following two commits. > > > > I did this patch on seeing 761fe7bc8193b7. But a closer look > > indicates that the following two patches disable the filemap > > VM_FAULT_RETRY part totally... > > > > Anyway, if these two patches are to be reverted somehow(I guess yes), > > this patch shall be _ignored_. > > > > btw, do you have any test case and performance numbers for > > FAULT_FLAG_RETRY? And possible overheads for (the worst case) > > sparse random mmap reads on a sparse file? I cannot find any > > in your changelogs.. > > here is the benchmark i posted on [V1] but somehow missed in [V2] describtion > > Benchmarks: > case 1. one application has a high count of threads each faulting in > different pages of a hugefile. Benchmark indicate that this double data > structure walking in case of major fault results in << 1% performance hit. > > case 2. add another thread in the above application which in a tight loop of > mmap()/munmap(). Here we measure loop count in the new thread while other > threads doing the same amount of work as case one. we got << 3% performance > hit on the Complete Time(benchmark value for case one) and 10% performance > improvement on the mmap()/munmap() counter. > > This patch helps a lot in cases we have writer which is waitting behind all > readers, so it could execute much faster. > Just tested the sparse-random-read-on-sparse-file case, and found the performance impact to be 0.4% (8.706s vs 8.744s). Kind of acceptable. without FAULT_FLAG_RETRY: iotrace.rb --load stride-100 --mplay /mnt/btrfs-ram/sparse 3.28s user 5.39s system 99% cpu 8.692 total iotrace.rb --load stride-100 --mplay /mnt/btrfs-ram/sparse 3.17s user 5.54s system 99% cpu 8.742 total iotrace.rb --load stride-100 --mplay /mnt/btrfs-ram/sparse 3.18s user 5.48s system 99% cpu 8.684 total FAULT_FLAG_RETRY: iotrace.rb --load stride-100 --mplay /mnt/btrfs-ram/sparse 3.18s user 5.63s system 99% cpu 8.825 total iotrace.rb --load stride-100 --mplay /mnt/btrfs-ram/sparse 3.22s user 5.47s system 99% cpu 8.718 total iotrace.rb --load stride-100 --mplay /mnt/btrfs-ram/sparse 3.13s user 5.55s system 99% cpu 8.690 total In the above faked workload, the mmap read page offsets are loaded from stride-100 and performed on /mnt/btrfs-ram/sparse, which are created by: seq 0 100 1000000 > stride-100 dd if=/dev/zero of=/mnt/btrfs-ram/sparse bs=1M count=1 seek=1024000 Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/