[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20130924165848.4f3ba25b4de236fa746fb7ee@linux-foundation.org>
Date: Tue, 24 Sep 2013 16:58:48 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Andi Kleen <ak@...ux.intel.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Al Viro <viro@...iv.linux.org.uk>,
Hugh Dickins <hughd@...gle.com>,
Wu Fengguang <fengguang.wu@...el.com>, Jan Kara <jack@...e.cz>,
Mel Gorman <mgorman@...e.de>, linux-mm@...ck.org,
Matthew Wilcox <willy@...ux.intel.com>,
"Kirill A. Shutemov" <kirill@...temov.name>,
Hillf Danton <dhillf@...il.com>, Dave Hansen <dave@...1.net>,
Ning Qu <quning@...gle.com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv6 00/22] Transparent huge page cache: phase 1,
everything but mmap()
On Tue, 24 Sep 2013 16:49:50 -0700 Andi Kleen <ak@...ux.intel.com> 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists