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=-6.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 A025CC3F2C6 for ; Tue, 3 Mar 2020 21:47:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 50ADC20728 for ; Tue, 3 Mar 2020 21:47:56 +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="RNb94WO7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 50ADC20728 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 D68D56B0005; Tue, 3 Mar 2020 16:47:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D19906B0006; Tue, 3 Mar 2020 16:47:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C089F6B0007; Tue, 3 Mar 2020 16:47:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0037.hostedemail.com [216.40.44.37]) by kanga.kvack.org (Postfix) with ESMTP id A8EF26B0005 for ; Tue, 3 Mar 2020 16:47:55 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3E4138248D51 for ; Tue, 3 Mar 2020 21:47:55 +0000 (UTC) X-FDA: 76555388910.20.worm18_adefa23f201f X-HE-Tag: worm18_adefa23f201f X-Filterd-Recvd-Size: 4768 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Tue, 3 Mar 2020 21:47:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.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=MTkxZDhZ2/iSNNpC41qnrR0EVYdrFtYtY3L14eg0A9U=; b=RNb94WO7W/fnx08pWbYKizHBcP +Flw56zu0Fhd1nk2Cj4KmbFhIXQxmryZF0u7lJUt2J/0wKw7EPTidh10FnPXHArYlviNeVuKB3TUV vO3dai/CTP30ad4yi78wkzv+q8fQUowA8IZiRXH8TxQkjpjUjf4GzxGQUhQlXcJz0QQ95j8aDDXoY 7j+DZsp0rzGrO/O3dUMEYnz1so5Q9VBqHx9sadHQa0YgFGWkpZYkWws/z9dKlPDMEaG3ArZS3yPOp NKxcgXVDFOj+MfxNEr9DZqdV9rvbfEqMqOHHVvMyhYEiiTdSKWjK68F8r4JwrTA7KBs6smowaZ/rS G9kiiB9g==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1j9FOJ-0004eZ-T2; Tue, 03 Mar 2020 21:47:51 +0000 Date: Tue, 3 Mar 2020 13:47:51 -0800 From: Matthew Wilcox To: Alexander Duyck Cc: linux-mm , "Kirill A . Shutemov" Subject: Re: [PATCH 2/6] mm: Optimise find_subpage for !THP Message-ID: <20200303214751.GW29971@bombadil.infradead.org> References: <20200303041125.19358-1-willy@infradead.org> <20200303041125.19358-3-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, Mar 03, 2020 at 01:28:13PM -0800, Alexander Duyck wrote: > On Mon, Mar 2, 2020 at 8:11 PM Matthew Wilcox wrote: > > From: "Matthew Wilcox (Oracle)" > > > > If THP is disabled, find_subpage can become a no-op. > > > > Signed-off-by: Matthew Wilcox (Oracle) > > Acked-by: Kirill A. Shutemov > > --- > > include/linux/pagemap.h | 15 ++++++++++----- > > 1 file changed, 10 insertions(+), 5 deletions(-) > > > > diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h > > index b4ea3a5d00e5..8785f60b05f8 100644 > > --- a/include/linux/pagemap.h > > +++ b/include/linux/pagemap.h > > @@ -333,14 +333,19 @@ static inline struct page *grab_cache_page_nowait(struct address_space *mapping, > > mapping_gfp_mask(mapping)); > > } > > > > -static inline struct page *find_subpage(struct page *page, pgoff_t offset) > > +/* > > + * Given the page we found in the page cache, return the page corresponding > > + * to this offset in the file > > + */ > > +static inline struct page *find_subpage(struct page *head, pgoff_t offset) > > { > > - if (PageHuge(page)) > > - return page; > > + /* HugeTLBfs wants the head page regardless */ > > + if (PageHuge(head)) > > + return head; > > > > - VM_BUG_ON_PAGE(PageTail(page), page); > > + VM_BUG_ON_PAGE(PageTail(head), head); > > Is there any specific reason for renaming page to head? Just wondering Christoph Hellwig asked for the rename in an earlier version of this patchset. > since it adds some noise to the patch that wasn't really called out in > the patch description. From what I can tell none of the changes above > this point have any explanation to them in the patch description, and > until I noticed the change below I thought maybe you had the wrong > patch description for this patch. > > > - return page + (offset & (compound_nr(page) - 1)); > > + return head + (offset & (hpage_nr_pages(head) - 1)); > > } > > So the patch description refers to this line here, correct? Yes, that's the actual change. > One thing I am noticing is that it looks like the VM_BUG_ON_PAGE is > now redundant. If I am not not mistaken hpage_nr_pages will call > PageTransHuge which also performs the same check. So do you still need > the VM_BUG_ON_PAGE call in this function? Huh, I didn't know PageTransHuge had that. I suppose it can go, although there's only a call to PageTransHuge() in the CONFIG_TRANSPARENT_HUGEPAGE enabled case. You might ask how a tail page could get into the page cache if CONFIG_TRANSPARENT_HUGEPAGE is not enabled, and I would not have a good answer for that ... although if one has, I think we'd want to know about it. So maybe that's a good reason to keep the explicit check, or maybe it's a good reason to make hpage_nr_pages() check that assertion if !CONFIG_TRANSPARENT_HUGEPAGE.