From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15E70C433DF for ; Thu, 21 May 2020 22:49:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BA8D4207F9 for ; Thu, 21 May 2020 22:49:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BA8D4207F9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fromorbit.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6872280009; Thu, 21 May 2020 18:49:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 637C780007; Thu, 21 May 2020 18:49:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 525DE80009; Thu, 21 May 2020 18:49:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0060.hostedemail.com [216.40.44.60]) by kanga.kvack.org (Postfix) with ESMTP id 39DE680007 for ; Thu, 21 May 2020 18:49:11 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id F38E2381E for ; Thu, 21 May 2020 22:49:10 +0000 (UTC) X-FDA: 76842218460.21.vase10_3300f3f233237 X-HE-Tag: vase10_3300f3f233237 X-Filterd-Recvd-Size: 4016 Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Thu, 21 May 2020 22:49:10 +0000 (UTC) Received: from dread.disaster.area (pa49-195-157-175.pa.nsw.optusnet.com.au [49.195.157.175]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 480C282078A; Fri, 22 May 2020 08:49:08 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1jbtzu-0000hq-Ta; Fri, 22 May 2020 08:49:06 +1000 Date: Fri, 22 May 2020 08:49:06 +1000 From: Dave Chinner To: Matthew Wilcox Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 00/36] Large pages in the page cache Message-ID: <20200521224906.GU2005@dread.disaster.area> References: <20200515131656.12890-1-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200515131656.12890-1-willy@infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=X6os11be c=1 sm=1 tr=0 a=ONQRW0k9raierNYdzxQi9Q==:117 a=ONQRW0k9raierNYdzxQi9Q==:17 a=kj9zAlcOel0A:10 a=sTwFKg_x9MkA:10 a=JfrnYn6hAAAA:8 a=7-415B0cAAAA:8 a=2DAmyFJ7tbF1Kr5hZtcA:9 a=CjuIK1q_8ugA:10 a=1CNFftbPRP8L7MoqJWF3:22 a=biEYGPWJfzWAr4FL6Ov7:22 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, May 15, 2020 at 06:16:20AM -0700, Matthew Wilcox wrote: > From: "Matthew Wilcox (Oracle)" > > This patch set does not pass xfstests. Test at your own risk. It is > based on the readahead rewrite which is in Andrew's tree. I've fixed a > lot of issues in the last two weeks, but generic/013 will still crash it. > > The primary idea here is that a large part of the overhead in dealing > with individual pages is that there's just so darned many of them. > We would be better off dealing with fewer, larger pages, even if they > don't get to be the size necessary for the CPU to use a larger TLB entry. Ok, so the main issue I have with the filesystem/iomap side of things is that it appears to be adding "transparent huge page" awareness to the filesysetm code, not "large page support". For people that aren't aware of the difference between the transparent huge and and a normal compound page (e.g. I have no idea what the difference is), this is likely to cause problems, especially as you haven't explained at all in this description why transparent huge pages are being used rather than bog standard compound pages. And, really, why should iomap or the filesystems care if the large page is a THP or just a high order compound page? The interface for operating on these things at the page cache level should be the same. We already have page_size() and friends for operating on high order compound pages, yet the iomap stuff has this new thp_size() function instead of just using page_size(). THis is going to lead to confusion and future bugs when people who don't know the difference use the wrong page size function in their filesystem code. So, really, the "large page" API presented to the filesystems via the page cache needs to be unified. Having to use compound_*() in some places, thp_* in others, then page_* and Page*, not to mention hpage_* just so that we can correctly support "large pages" is a total non-starter. Hence I'd suggest that this patch set needs to start by "hiding" all the differences between different types of pages behind a unified, consistent API, then it can introduce large page support into code outside the mm/ infrastructure via that unified API. I don't care what that API looks like so long as it is clear, consistenti, well documented and means filesystem developers don't need to know anything about how the page (large or not) is managed by the mm subsystem. Cheers, Dave. -- Dave Chinner david@fromorbit.com