From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [PATCHv4 00/39] Transparent huge page cache Date: Tue, 21 May 2013 11:37:16 -0700 Message-ID: <519BBEDC.1030607@sr71.net> References: <1368321816-17719-1-git-send-email-kirill.shutemov@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andrea Arcangeli , Andrew Morton , Al Viro , Hugh Dickins , Wu Fengguang , Jan Kara , Mel Gorman , linux-mm@kvack.org, Andi Kleen , Matthew Wilcox , "Kirill A. Shutemov" , Hillf Danton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: "Kirill A. Shutemov" Return-path: In-Reply-To: <1368321816-17719-1-git-send-email-kirill.shutemov@linux.intel.com> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On 05/11/2013 06:22 PM, Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > It's version 4. You can also use git tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git > > branch thp/pagecache. > > If you want to check changes since v3 you can look at diff between tags > thp/pagecache/v3 and thp/pagecache/v4-prerebase. What's the purpose of posting these patches? Do you want them merged? Or are they useful as they stand, or are they just here so folks can play with them as you improve them? > The goal of the project is preparing kernel infrastructure to handle huge > 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. It provides information on what > performance boost we should expect on other files systems. Do you think folks would use ramfs in practice? Or is this just a toy? Could this replace some (or all) existing hugetlbfs use, for instance? -- 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 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755614Ab3EUShU (ORCPT ); Tue, 21 May 2013 14:37:20 -0400 Received: from www.sr71.net ([198.145.64.142]:44013 "EHLO blackbird.sr71.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751851Ab3EUShS (ORCPT ); Tue, 21 May 2013 14:37:18 -0400 Message-ID: <519BBEDC.1030607@sr71.net> Date: Tue, 21 May 2013 11:37:16 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Kirill A. Shutemov" CC: Andrea Arcangeli , Andrew Morton , Al Viro , Hugh Dickins , Wu Fengguang , Jan Kara , Mel Gorman , linux-mm@kvack.org, Andi Kleen , Matthew Wilcox , "Kirill A. Shutemov" , Hillf Danton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv4 00/39] Transparent huge page cache References: <1368321816-17719-1-git-send-email-kirill.shutemov@linux.intel.com> In-Reply-To: <1368321816-17719-1-git-send-email-kirill.shutemov@linux.intel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/11/2013 06:22 PM, Kirill A. Shutemov wrote: > From: "Kirill A. Shutemov" > > It's version 4. You can also use git tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git > > branch thp/pagecache. > > If you want to check changes since v3 you can look at diff between tags > thp/pagecache/v3 and thp/pagecache/v4-prerebase. What's the purpose of posting these patches? Do you want them merged? Or are they useful as they stand, or are they just here so folks can play with them as you improve them? > The goal of the project is preparing kernel infrastructure to handle huge > 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. It provides information on what > performance boost we should expect on other files systems. Do you think folks would use ramfs in practice? Or is this just a toy? Could this replace some (or all) existing hugetlbfs use, for instance?