From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by kanga.kvack.org (Postfix) with ESMTP id A4DCE6B006E for ; Fri, 28 Feb 2014 17:36:10 -0500 (EST) Received: by mail-vc0-f174.google.com with SMTP id im17so1405325vcb.33 for ; Fri, 28 Feb 2014 14:36:10 -0800 (PST) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [2607:f8b0:400c:c01::22e]) by mx.google.com with ESMTPS id f5si815913vej.35.2014.02.28.14.36.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 14:36:10 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id oz11so501566veb.33 for ; Fri, 28 Feb 2014 14:36:09 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20140228143440.e0ec026baeced2efbb52aa50@linux-foundation.org> References: <1393625931-2858-1-git-send-email-quning@google.com> <20140228143440.e0ec026baeced2efbb52aa50@linux-foundation.org> From: Ning Qu Date: Fri, 28 Feb 2014 14:35:28 -0800 Message-ID: Subject: Re: [PATCH 0/1] mm, shmem: map few pages around fault address if they are in page cache Content-Type: multipart/alternative; boundary=001a1136516c7ca5f304f37f1029 Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: Linus Torvalds , Mel Gorman , Rik van Riel , "Kirill A. Shutemov" , Andi Kleen , Matthew Wilcox , Dave Hansen , Alexander Viro , Dave Chinner , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Hugh Dickins --001a1136516c7ca5f304f37f1029 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable let me double check. Best wishes, --=20 Ning Qu (=E6=9B=B2=E5=AE=81) | Software Engineer | quning@google.com | +1-4= 08-418-6066 On Fri, Feb 28, 2014 at 2:34 PM, Andrew Morton w= rote: > On Fri, 28 Feb 2014 14:18:50 -0800 Ning Qu wrote: > > > This is a follow-up patch for "mm: map few pages around fault address i= f > they are in page cache" > > > > We use the generic filemap_map_pages as ->map_pages in shmem/tmpfs. > > > > Please cc Hugh on shmem/tmpfs things > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Below is just some simple experiment numbers from this patch, let me > know if > > you would like more: > > > > Tested on Xeon machine with 64GiB of RAM, using the current default fau= lt > > order 4. > > > > Sequential access 8GiB file > > Baseline with-patch > > 1 thread > > minor fault 205 101 > > Confused. Sequential access of an 8G file should generate 2,000,000 > minor faults, not 205. And with FAULT_AROUND_ORDER=3D4, that should come > down to 2,000,000/16 minor faults when using faultaround? > > > time, seconds 7.94 7.82 > > > > Random access 8GiB file > > Baseline with-patch > > 1 thread > > minor fault 724 623 > > time, seconds 9.75 9.84 > > > > --001a1136516c7ca5f304f37f1029 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
let me double check.

Best wishes,
--=C2=A0
<= span style=3D"border-top-width:2px;border-right-width:0px;border-bottom-wid= th:0px;border-left-width:0px;border-top-style:solid;border-right-style:soli= d;border-bottom-style:solid;border-left-style:solid;border-top-color:rgb(21= 3,15,37);border-right-color:rgb(213,15,37);border-bottom-color:rgb(213,15,3= 7);border-left-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Ning Qu= (=E6=9B=B2=E5=AE=81)=C2=A0|=C2=A0Software Engineer |=C2=A0quning@go= ogle.com=C2=A0|=C2=A0+1-408-418-6066


On Fri, Feb 28, 2014 at 2:34 PM, Andrew = Morton <akpm@linux-foundation.org> wrote:
On Fri, 28 Feb 2014 14:18:50 -0800 Ning Qu <quning@google.com> wrote:

> This is a follow-up patch for "mm: map few pages around fault add= ress if they are in page cache"
>
> We use the generic filemap_map_pages as ->map_pages in shmem/tmpfs.=
>

Please cc Hugh on shmem/tmpfs things

>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> Below is just some simple experiment numbers from this patch, let me k= now if
> you would like more:
>
> Tested on Xeon machine with 64GiB of RAM, using the current default fa= ult
> order 4.
>
> Sequential access 8GiB file
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Baseline =C2=A0 =C2=A0 =C2=A0 =C2=A0with-patch
> 1 thread
> =C2=A0 =C2=A0 minor fault =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 205 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 101

Confused. =C2=A0Sequential access of an 8G file should generate 2,000= ,000
minor faults, not 205. =C2=A0And with FAULT_AROUND_ORDER=3D4, that should c= ome
down to 2,000,000/16 minor faults when using faultaround?

> =C2=A0 =C2=A0 time, seconds =C2=A0 =C2=A0 7.94 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A07.82
>
> Random access 8GiB file
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Baseline =C2=A0 =C2=A0 =C2=A0 =C2=A0with-patch
> 1 thread
> =C2=A0 =C2=A0 minor fault =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 724 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 623
> =C2=A0 =C2=A0 time, seconds =C2=A0 =C2=A0 9.75 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A09.84
>


--001a1136516c7ca5f304f37f1029-- -- 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