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=-5.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,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 459BEC4742C for ; Fri, 13 Nov 2020 06:39:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9F90A20B80 for ; Fri, 13 Nov 2020 06:39:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="LQdZl2eF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F90A20B80 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E9EF06B0068; Fri, 13 Nov 2020 01:39:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E27E76B006C; Fri, 13 Nov 2020 01:39:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA0146B006E; Fri, 13 Nov 2020 01:39:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0106.hostedemail.com [216.40.44.106]) by kanga.kvack.org (Postfix) with ESMTP id 9553D6B0068 for ; Fri, 13 Nov 2020 01:39:13 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 39F3E8249980 for ; Fri, 13 Nov 2020 06:39:13 +0000 (UTC) X-FDA: 77478442986.14.cart67_4b05c342730c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id 1654A18229818 for ; Fri, 13 Nov 2020 06:39:13 +0000 (UTC) X-HE-Tag: cart67_4b05c342730c X-Filterd-Recvd-Size: 4572 Received: from hqnvemgate26.nvidia.com (hqnvemgate26.nvidia.com [216.228.121.65]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Fri, 13 Nov 2020 06:39:12 +0000 (UTC) Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate26.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Thu, 12 Nov 2020 22:39:14 -0800 Received: from [10.2.88.49] (10.124.1.5) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 13 Nov 2020 06:39:10 +0000 Subject: Re: Are THPs the right model for the pagecache? To: Matthew Wilcox , , References: <20201113044652.GD17076@casper.infradead.org> From: John Hubbard Message-ID: <1c1fa264-41d8-49a4-e5ff-2a5bf03e711e@nvidia.com> Date: Thu, 12 Nov 2020 22:39:10 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:83.0) Gecko/20100101 Thunderbird/83.0 MIME-Version: 1.0 In-Reply-To: <20201113044652.GD17076@casper.infradead.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.124.1.5] X-ClientProxiedBy: HQMAIL105.nvidia.com (172.20.187.12) To HQMAIL107.nvidia.com (172.20.187.13) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1605249554; bh=+1vV61r7aJj+On/1WUVh0pXSx4Oswbb+NFAZtUFkoBE=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Content-Language: Content-Transfer-Encoding:X-Originating-IP:X-ClientProxiedBy; b=LQdZl2eFaox5PQyMRMTZgGaXiEf1gUoev0CGO+NElMFQgz8hdeAi+wH9/f+zdLgxp uXIs3boyp3RSESOB5Q6WDaVrGBQam7aKbTI5hpEKihINCg9NxGIVWRmQ14HjD6WdB3 vKLKDrm83uOGWy57cVPlGzZMR14jrrR9qPuFctCpETtGTM5LaDxLgcencYww/rJLfs FNd20+OxZmirH6JbFiA72pszP2ZQC4ExwBcgd2FL1Fs6Epe0RXEcrkPlc9kiXbm24O qXOOoYW8+npPsys/vTVH21sfLfzhJAiaHqiUoYQDqIaAny9I9CnDg6Rc9SdGjsUm5N O/e5Xo06Khk5Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001710, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 11/12/20 8:46 PM, Matthew Wilcox wrote: > When I started working on using larger pages in the page cache, I was > thinking about calling them large pages or lpages. As I worked my way > through the code, I switched to simply adopting the transparent huge > page terminology that is used by anonymous and shmem. I just changed > the definition so that a thp is a page of arbitrary order. > > But now I'm wondering if that expediency has brought me to the right > place. To enable THP, you have to select CONFIG_TRANSPARENT_HUGEPAGE, > which is only available on architectures which support using larger TLB > entries to map PMD-sized pages. Fair enough, since that was the original > definition, but the point of suppoting larger page sizes in the page > cache is to reduce software overhead. Why shouldn't Alpha or m68k use > large pages in the page cache, even if they can't use them in their TLBs? > > I'm also thinking about the number of asserts about > PageHead/PageTail/PageCompound and the repeated invocations of > compound_head(). If we had a different type for large pages, we could use > the compiler to assert these things instead of putting in runtime asserts. This seems like a really good idea to me, anyway. Even in the fairly small area of gup.c, some type safety (normal pages vs. large pages) would have helped keep things straight when I was fooling around with pinning pages. > > 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? Given that you've said we could get compile time asserts, I guess you're not envisioning writing any code that could get the first case at runtime? thanks, -- John Hubbard NVIDIA