From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by kanga.kvack.org (Postfix) with ESMTP id 0B8996B0031 for ; Tue, 24 Sep 2013 19:48:26 -0400 (EDT) Received: by mail-pb0-f47.google.com with SMTP id rr4so5236783pbb.34 for ; Tue, 24 Sep 2013 16:48:26 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id g17so4004750vbg.0 for ; Tue, 24 Sep 2013 16:48:24 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20130924163740.4bc7db61e3e520798220dc4c@linux-foundation.org> References: <1379937950-8411-1-git-send-email-kirill.shutemov@linux.intel.com> <20130924163740.4bc7db61e3e520798220dc4c@linux-foundation.org> From: Ning Qu Date: Tue, 24 Sep 2013 16:48:03 -0700 Message-ID: Subject: Re: [PATCHv6 00/22] Transparent huge page cache: phase 1, everything but mmap() Content-Type: multipart/alternative; boundary=20cf307cfd68ba009704e729c5f7 Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: "Kirill A. Shutemov" , Andrea Arcangeli , Al Viro , Hugh Dickins , Wu Fengguang , Jan Kara , Mel Gorman , linux-mm@kvack.org, Andi Kleen , Matthew Wilcox , "Kirill A. Shutemov" , Hillf Danton , Dave Hansen , Alexander Shishkin , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org --20cf307cfd68ba009704e729c5f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am working on the tmpfs side on top of this patchset, which I assume has better applications usage than ramfs. However, I am working on 3.3 so far and will probably get my patches ported to upstream pretty soon. I believe my patchset is also in early stage but it does help to get some solid numbers in our own projects, which is very convincing. However, I think it does depend on the characteristic of the job ..... Best wishes, --=20 Ning Qu (=E6=9B=B2=E5=AE=81) | Software Engineer | quning@google.com | +1-4= 08-418-6066 On Tue, Sep 24, 2013 at 4:37 PM, Andrew Morton w= rote: > On Mon, 23 Sep 2013 15:05:28 +0300 "Kirill A. Shutemov" < > kirill.shutemov@linux.intel.com> wrote: > > > It brings thp support for ramfs, but without mmap() -- it will be poste= d > > separately. > > We were never going to do this :( > > Has anyone reviewed these patches much yet? > > > Please review and consider applying. > > It appears rather too immature at this stage. > > > Intro > > ----- > > > > The goal of the project is preparing kernel infrastructure to handle hu= ge > > pages in page cache. > > > > To proof that the proposed changes are functional we enable the feature > > for the most simple file system -- ramfs. ramfs is not that useful by > > itself, but it's good pilot project. > > At the very least we should get this done for a real filesystem to see > how intrusive the changes are and to evaluate the performance changes. > > > Sigh. A pox on whoever thought up huge pages. Words cannot express > how much of a godawful mess they have made of Linux MM. And it hasn't > ended yet :( My take is that we'd need to see some very attractive and > convincing real-world performance numbers before even thinking of > taking this on. > > > > --20cf307cfd68ba009704e729c5f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am working on the tmpfs side on top of this patchset, wh= ich I assume has better applications usage than ramfs.

H= owever, I am working on 3.3 so far and will probably get my patches ported = to upstream pretty soon. I believe my patchset is also in early stage but i= t does help to get some solid numbers in our own projects, which is very co= nvincing. However, I think it does depend on the characteristic of the job = .....



Best wishes,
--=C2=A0
Ning = Qu (=E6=9B=B2=E5=AE=81)=C2=A0|=C2=A0Software Engineer |=C2=A0quning@= google.com=C2=A0|=C2=A0+1-408-418-6066


On Tue, Sep 24, 2013 at 4:37 PM, Andrew = Morton <akpm@linux-foundation.org> wrote:
On Mon, 23 Sep 2013 15:05:28 +0300 "Kirill A. Shutem= ov" <kirill.shut= emov@linux.intel.com> wrote:

> It brings thp support for ramfs, but without mmap() -- it will be post= ed
> separately.

We were never going to do this :(

Has anyone reviewed these patches much yet?

> Please review and consider applying.

It appears rather too immature at this stage.

> Intro
> -----
>
> The goal of the project is preparing kernel infrastructure to handle h= uge
> pages in page cache.
>
> To proof that the proposed changes are functional we enable the featur= e
> for the most simple file system -- ramfs. ramfs is not that useful by<= br> > itself, but it's good pilot project.

At the very least we should get this done for a real filesystem to se= e
how intrusive the changes are and to evaluate the performance changes.


Sigh. =C2=A0A pox on whoever thought up huge pages. =C2=A0Words cannot expr= ess
how much of a godawful mess they have made of Linux MM. =C2=A0And it hasn&#= 39;t
ended yet :( My take is that we'd need to see some very attractive and<= br> convincing real-world performance numbers before even thinking of
taking this on.




--20cf307cfd68ba009704e729c5f7-- -- 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