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.6 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 DE923C433DB for ; Wed, 27 Jan 2021 02:25:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7B1B42063A for ; Wed, 27 Jan 2021 02:25:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7B1B42063A 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 A9FE26B0005; Tue, 26 Jan 2021 21:25:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A51D26B0006; Tue, 26 Jan 2021 21:25:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F4E86B0007; Tue, 26 Jan 2021 21:25:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0088.hostedemail.com [216.40.44.88]) by kanga.kvack.org (Postfix) with ESMTP id 75D4C6B0005 for ; Tue, 26 Jan 2021 21:25:00 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3A56F3636 for ; Wed, 27 Jan 2021 02:25:00 +0000 (UTC) X-FDA: 77749962360.04.pot26_3317a9127593 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 1278E80105A0 for ; Wed, 27 Jan 2021 02:25:00 +0000 (UTC) X-HE-Tag: pot26_3317a9127593 X-Filterd-Recvd-Size: 3435 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Wed, 27 Jan 2021 02:24:57 +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=60WoA0haalgCAug6TGsXGutfGgc3qh6P4UHF0YYcunc=; b=mI2AtubiUQoYZfxsg0Q/vN6JmI 4CdZ092ntuvOBqOowp3+K+9wzzo/RP9CY2aTZj/zfnZuGlVixoIyUqnRS8/4FcBRaaVZTaeKHvLr5 Bfps/iMMOOiaBxbQA1hQTxFkSB5BfBFJl9UpSMFsC4dEA3Ha+K/AZttGdxivvzBjnmbhvHZ9KqDK5 91MjTe3DC2qFQBFUoVKDak8vOVET3IO5Wpmi4qk4rfKhrR5MPZhgZEXL5UnlPzsISsumGB1qjCkzO mU30vp5xW4bDMp6uTqXR8cUgSvcHhmGsrkpUNBx20jPRA8hWIF3KyXbAHgS3An1SckSoTDQPcD0Cn 7RbjZwMQ==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1l4aVa-006WTR-Kv; Wed, 27 Jan 2021 02:24:41 +0000 Date: Wed, 27 Jan 2021 02:24:38 +0000 From: Matthew Wilcox To: Jason Gunthorpe Cc: Mike Kravetz , Joao Martins , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , John Hubbard , Zi Yan Subject: Re: [PATCH 2/2] mm/hugetlb: refactor subpage recording Message-ID: <20210127022438.GQ308988@casper.infradead.org> References: <20210125205744.10203-1-joao.m.martins@oracle.com> <20210125205744.10203-3-joao.m.martins@oracle.com> <3d34111f-8365-ab95-af11-aaf4825204be@oracle.com> <1ae0313d-de9b-4553-1f68-04c4f5a3f7eb@oracle.com> <4d3914e9-f448-8a86-9fc6-e71cec581115@oracle.com> <20210127000730.GB4605@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210127000730.GB4605@ziepe.ca> 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 Tue, Jan 26, 2021 at 08:07:30PM -0400, Jason Gunthorpe wrote: > I'm looking at Matt's folio patches and see: > > +static inline struct folio *next_folio(struct folio *folio) > +{ > + return folio + folio_nr_pages(folio); > +} This is a replacement for places that would do 'page++'. eg it's used by the bio iterator where we already checked that the phys addr and the struct page are contiguous. > And checking page_trans_huge_mapcount(): > > for (i = 0; i < thp_nr_pages(page); i++) { > mapcount = atomic_read(&page[i]._mapcount) + 1; I think we are guaranteed this for transparent huge pages. At least for now. Zi Yan may have some thoughts for his work on 1GB transhuge pages ... > And we have the same logic in hmm_vma_walk_pud(): > > if (pud_huge(pud) && pud_devmap(pud)) { > pfn = pud_pfn(pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT); > for (i = 0; i < npages; ++i, ++pfn) > hmm_pfns[i] = pfn | cpu_flags; > > So, if page[n] does not access the tail pages of a compound we have > many more people who are surprised by this than just GUP. > > Where are these special rules for hugetlb compound tails documented? > Why does it need to be like this? > > Isn't it saner to forbid a compound and its tails from being > non-linear in the page array? That limits when compounds can be > created, but seems more likely to happen than a full mm audit to find > all the places that assume linearity. > > Jason