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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 CBC2BC56202 for ; Fri, 13 Nov 2020 12:38:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BA38F20797 for ; Fri, 13 Nov 2020 12:38:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="hvlA99gU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BA38F20797 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F1AD86B0080; Fri, 13 Nov 2020 07:38:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EA5686B0087; Fri, 13 Nov 2020 07:38:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D6B816B0089; Fri, 13 Nov 2020 07:38:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0063.hostedemail.com [216.40.44.63]) by kanga.kvack.org (Postfix) with ESMTP id A07916B0080 for ; Fri, 13 Nov 2020 07:38:40 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3A8FF8249980 for ; Fri, 13 Nov 2020 12:38:40 +0000 (UTC) X-FDA: 77479348800.22.sound63_4c0792e2730f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 1D7A618038E67 for ; Fri, 13 Nov 2020 12:38:40 +0000 (UTC) X-HE-Tag: sound63_4c0792e2730f X-Filterd-Recvd-Size: 3770 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Fri, 13 Nov 2020 12:38:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=RYLmEpvBz+t57yvqN9GmWpxhfukhqfsT/7cprwXn3vM=; b=hvlA99gUbacmKAw5wr3w/hPyYa gXC2WwVnunDrt+cySAhx/QTYSIGZoMEXgfxxgDQB3gHCqG7hy3Z9Nkn8ucJEBJ7VOm8rrW+nEdFY6 /b4piYt2+3uvK1/tWp0BjUenTa5Kh9v1MJZ9G+wsP+tUr3PrF/BQ4BA7D82zL29ujAn4XaJ8bH1sL LnwLHb7YejNUJ3W8TmcBETBzx1tkPbSj183yrd+7UoDAaZYHBHir+ubCYfrVIXHxDr5G9zv4V3tuO FgG2kQvOPuItySyH/4OP70Q4XMqUhBHIsw7lyQrjQzwX+D8lA+e0Leru9OQltb9SY8ciZW+0p9sFQ lGiUTz/w==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kdYLc-0005bn-B7; Fri, 13 Nov 2020 12:38:36 +0000 Date: Fri, 13 Nov 2020 12:38:36 +0000 From: Matthew Wilcox To: John Hubbard Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: Are THPs the right model for the pagecache? Message-ID: <20201113123836.GE17076@casper.infradead.org> References: <20201113044652.GD17076@casper.infradead.org> <1c1fa264-41d8-49a4-e5ff-2a5bf03e711e@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1c1fa264-41d8-49a4-e5ff-2a5bf03e711e@nvidia.com> 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 Thu, Nov 12, 2020 at 10:39:10PM -0800, John Hubbard wrote: > > IOWs, something like this: > > > > struct lpage { > > struct page subpages[4]; > > }; > > > > static inline struct lpage *page_lpage(struct page *page) > > { > > unsigned long head = READ_ONCE(page->compound_head); > > > > if (unlikely(head & 1)) > > return (struct lpage *)(head - 1); > > return (struct lpage *)page; > > } > > This is really a "get_head_page()" function, not a "get_large_page()" > function. But even renaming it doesn't seem quite right, because > wouldn't it be better to avoid discarding that tail bit information? In > other words, you might be looking at 3 cases, one of which is *not* > involving large pages at all: > > The page is a single, non-compound page. > The page is a head page of a compound page > The page is a tail page of a compound page > > ...but this function returns a type of "large page", even for the first > case. That's misleading, isn't it? Argh. Yes, that's part of the problem, so this is still confusing. An lpage might actually be an order-0 page. Maybe it needs to be called something that's not 'page' at all. There are really four cases: - An order-0 page - A subpage that happens to be a tail page - A subpage that happens to be a head page - An order-N page We have code today that treats tail pages as order-0 pages, but if the subpage you happen to pass in is a head page, it'll work on the entire page. That must, surely, be a bug. So what if we had: /* Cache memory */ struct cmem { struct page pages[1]; }; Now there's a clear hierarchy. The page cache stores pointers to cmem. struct page *cmem_page(struct cmem *cmem, pgoff_t index) { return cmem->pages[index - cmem->pages[0].index]; } struct cmem *page_cmem(struct page *page) { unsigned long head = READ_ONCE(page->compound_head); if (unlikely(head & 1)) return (struct cmem *)(head - 1); return (struct cmem *)page; } and we'll need the usualy panoply of functions to get the order/size/... of a cmem. We'll also need functions like CMemDirty(), CMemLocked(), CMemWriteback(), etc.