Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765999Ab3DEBYn (ORCPT ); Thu, 4 Apr 2013 21:24:43 -0400 Received: from mail-da0-f44.google.com ([209.85.210.44]:55548 "EHLO mail-da0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1765984Ab3DEBYl (ORCPT ); Thu, 4 Apr 2013 21:24:41 -0400 Message-ID: <515E27D0.5090105@gmail.com> Date: Fri, 05 Apr 2013 09:24:32 +0800 From: Ric Mason User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Hugh Dickins CC: "Kirill A. Shutemov" , Andrea Arcangeli , Andrew Morton , Al Viro , Wu Fengguang , Jan Kara , Mel Gorman , linux-mm@kvack.org, Andi Kleen , Matthew Wilcox , "Kirill A. Shutemov" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH, RFC 00/16] Transparent huge page cache References: <1359365068-10147-1-git-send-email-kirill.shutemov@linux.intel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4385 Lines: 100 Hi Hugh, On 01/29/2013 01:03 PM, Hugh Dickins wrote: > On Mon, 28 Jan 2013, Kirill A. Shutemov wrote: >> From: "Kirill A. Shutemov" >> >> Here's first steps towards huge pages in page cache. >> >> The intend of the work is get code ready to enable transparent huge page >> cache for the most simple fs -- ramfs. >> >> It's not yet near feature-complete. It only provides basic infrastructure. >> At the moment we can read, write and truncate file on ramfs with huge pages in >> page cache. The most interesting part, mmap(), is not yet there. For now >> we split huge page on mmap() attempt. >> >> I can't say that I see whole picture. I'm not sure if I understand locking >> model around split_huge_page(). Probably, not. >> Andrea, could you check if it looks correct? >> >> Next steps (not necessary in this order): >> - mmap(); >> - migration (?); >> - collapse; >> - stats, knobs, etc.; >> - tmpfs/shmem enabling; >> - ... >> >> Kirill A. Shutemov (16): >> block: implement add_bdi_stat() >> mm: implement zero_huge_user_segment and friends >> mm: drop actor argument of do_generic_file_read() >> radix-tree: implement preload for multiple contiguous elements >> thp, mm: basic defines for transparent huge page cache >> thp, mm: rewrite add_to_page_cache_locked() to support huge pages >> thp, mm: rewrite delete_from_page_cache() to support huge pages >> thp, mm: locking tail page is a bug >> thp, mm: handle tail pages in page_cache_get_speculative() >> thp, mm: implement grab_cache_huge_page_write_begin() >> thp, mm: naive support of thp in generic read/write routines >> thp, libfs: initial support of thp in >> simple_read/write_begin/write_end >> thp: handle file pages in split_huge_page() >> thp, mm: truncate support for transparent huge page cache >> thp, mm: split huge page on mmap file page >> ramfs: enable transparent huge page cache >> >> fs/libfs.c | 54 +++++++++--- >> fs/ramfs/inode.c | 6 +- >> include/linux/backing-dev.h | 10 +++ >> include/linux/huge_mm.h | 8 ++ >> include/linux/mm.h | 15 ++++ >> include/linux/pagemap.h | 14 ++- >> include/linux/radix-tree.h | 3 + >> lib/radix-tree.c | 32 +++++-- >> mm/filemap.c | 204 +++++++++++++++++++++++++++++++++++-------- >> mm/huge_memory.c | 62 +++++++++++-- >> mm/memory.c | 22 +++++ >> mm/truncate.c | 12 +++ >> 12 files changed, 375 insertions(+), 67 deletions(-) > Interesting. > > I was starting to think about Transparent Huge Pagecache a few > months ago, but then got washed away by incoming waves as usual. > > Certainly I don't have a line of code to show for it; but my first > impression of your patches is that we have very different ideas of > where to start. > > Perhaps that's good complementarity, or perhaps I'll disagree with > your approach. I'll be taking a look at yours in the coming days, > and trying to summon back up my own ideas to summarize them for you. > > Perhaps I was naive to imagine it, but I did intend to start out > generically, independent of filesystem; but content to narrow down > on tmpfs alone where it gets hard to support the others (writeback > springs to mind). khugepaged would be migrating little pages into > huge pages, where it saw that the mmaps of the file would benefit > (and for testing I would hack mmap alignment choice to favour it). > > I had arrived at a conviction that the first thing to change was > the way that tail pages of a THP are refcounted, that it had been a > mistake to use the compound page method of holding the THP together. > But I'll have to enter a trance now to recall the arguments ;) One offline question, do you have any idea hugetlbfs pages support swapping? > > Hugh > > -- > 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 -- 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/