Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755231Ab3IYLPr (ORCPT ); Wed, 25 Sep 2013 07:15:47 -0400 Received: from mga02.intel.com ([134.134.136.20]:17143 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750832Ab3IYLPp (ORCPT ); Wed, 25 Sep 2013 07:15:45 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.90,978,1371106800"; d="scan'208";a="383299996" From: "Kirill A. Shutemov" To: Andrew Morton Cc: Andi Kleen , "Kirill A. Shutemov" , Andrea Arcangeli , Al Viro , Hugh Dickins , Wu Fengguang , Jan Kara , Mel Gorman , linux-mm@kvack.org, Matthew Wilcox , "Kirill A. Shutemov" , Hillf Danton , Dave Hansen , Ning Qu , Alexander Shishkin , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <20130924165848.4f3ba25b4de236fa746fb7ee@linux-foundation.org> References: <1379937950-8411-1-git-send-email-kirill.shutemov@linux.intel.com> <20130924163740.4bc7db61e3e520798220dc4c@linux-foundation.org> <20130924234950.GC2018@tassilo.jf.intel.com> <20130924165848.4f3ba25b4de236fa746fb7ee@linux-foundation.org> Subject: Re: [PATCHv6 00/22] Transparent huge page cache: phase 1, everything but mmap() Content-Transfer-Encoding: 7bit Message-Id: <20130925111538.CCE16E0090@blue.fi.intel.com> Date: Wed, 25 Sep 2013 14:15:38 +0300 (EEST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1476 Lines: 35 Andrew Morton wrote: > On Tue, 24 Sep 2013 16:49:50 -0700 Andi Kleen wrote: > > > > 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. > > > > That would give even larger patches, and people already complain > > the patchkit is too large. > > The thing is that merging an implementation for ramfs commits us to > doing it for the major real filesystems. Before making that commitment > we should at least have a pretty good understanding of what those > changes will look like. > > Plus I don't see how we can realistically performance-test it without > having real physical backing store in the picture? My plan for real filesystem is to get it first beneficial for read-mostly files: - allocate huge pages on read (or collapse small pages) only if nobody has the inode opened on write; - split huge page on write to avoid dealing with write back patch at first and dirty only 4k pages; This will will get most of elf executables and libraries mapped with huge pages (it may require dynamic linker change to align length to huge page boundary) which is not bad for start. -- Kirill A. Shutemov -- 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/