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=0.3 required=3.0 tests=BAYES_50,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 8E1D3C4361B for ; Wed, 9 Dec 2020 18:14:21 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D7D6B23C92 for ; Wed, 9 Dec 2020 18:14:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D7D6B23C92 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 4ADB0100EBB71; Wed, 9 Dec 2020 10:14:20 -0800 (PST) Received-SPF: None (mailfrom) identity=mailfrom; client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org; envelope-from=willy@infradead.org; receiver= Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id F263D100EBBBA for ; Wed, 9 Dec 2020 10:14:17 -0800 (PST) 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=lmGQgLGBhUH4rw9Xmb/x5bRo9Xb/oJgVLDZw+v+WbG8=; b=l4Gb5dTjEl4jTOb9r1drPUCMb8 EI+DUBz5nXgVqQ4+RIF7b9wFOcdEn35oPB7MFeCOb7VB1aSQ2leMN1lcd82W/egzjAo8NcH0A9QJF uzNNWQ4W6dTGzgm13wTb6XkYE7FNeEaGgafZn051CMIixzlkO1dwkXq8pr8sh4pKgD5PW8T0OLWM4 Lk2IXh1g22BWtZQoWLXIXXrYYh6hGsa1NzHMswvoerBibJq/IOx4zF2nXvB3PAkWlm6/Ll6B7N5Gq PRey6/BaANKDA+DyzKCUmcgqIehF9ghmad/JsbCQ6lklwoKB4mdCdbE5LbZJzr4F6wqsigaNzLHbd EF18VXjQ==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kn3yY-00080O-Qu; Wed, 09 Dec 2020 18:14:06 +0000 Date: Wed, 9 Dec 2020 18:14:06 +0000 From: Matthew Wilcox To: Jason Gunthorpe Subject: Re: [PATCH RFC 6/9] mm/gup: Grab head page refcount once for group of subpages Message-ID: <20201209181406.GQ7338@casper.infradead.org> References: <20201208172901.17384-1-joao.m.martins@oracle.com> <20201208172901.17384-8-joao.m.martins@oracle.com> <20201208194905.GQ5487@ziepe.ca> <20201209151505.GV5487@ziepe.ca> <20201209162438.GW5487@ziepe.ca> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201209162438.GW5487@ziepe.ca> Message-ID-Hash: RMDC6LXC7VKQTLC3ABQ2IFBVQVOGKM3M X-Message-ID-Hash: RMDC6LXC7VKQTLC3ABQ2IFBVQVOGKM3M X-MailFrom: willy@infradead.org X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation CC: Joao Martins , linux-mm@kvack.org, linux-nvdimm@lists.01.org, Muchun Song , Mike Kravetz , Andrew Morton X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, Dec 09, 2020 at 12:24:38PM -0400, Jason Gunthorpe wrote: > On Wed, Dec 09, 2020 at 04:02:05PM +0000, Joao Martins wrote: > > > Today (without the series) struct pages are not represented the way they > > are expressed in the page tables, which is what I am hoping to fix in this > > series thus initializing these as compound pages of a given order. But me > > introducing PGMAP_COMPOUND was to conservatively keep both old (non-compound) > > and new (compound pages) co-exist. > > Oooh, that I didn't know.. That is kind of horrible to have a PMD > pointing at an order 0 page only in this one special case. Uh, yes. I'm surprised it hasn't caused more problems. > Still, I think it would be easier to teach record_subpages() that a > PMD doesn't necessarily point to a high order page, eg do something > like I suggested for the SGL where it extracts the page order and > iterates over the contiguous range of pfns. But we also see good performance improvements from doing all reference counts on the head page instead of spread throughout the pages, so we really want compound pages. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org 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 A332FC4361B for ; Wed, 9 Dec 2020 18:14:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0259623C8E for ; Wed, 9 Dec 2020 18:14:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0259623C8E 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 62BA48D0032; Wed, 9 Dec 2020 13:14:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5DD588D0031; Wed, 9 Dec 2020 13:14:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4F10B8D0032; Wed, 9 Dec 2020 13:14:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0217.hostedemail.com [216.40.44.217]) by kanga.kvack.org (Postfix) with ESMTP id 3570F8D0031 for ; Wed, 9 Dec 2020 13:14:11 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E21143626 for ; Wed, 9 Dec 2020 18:14:10 +0000 (UTC) X-FDA: 77574543060.05.pigs64_050b0db273f1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id C1DD41801AB4B for ; Wed, 9 Dec 2020 18:14:10 +0000 (UTC) X-HE-Tag: pigs64_050b0db273f1 X-Filterd-Recvd-Size: 3209 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Wed, 9 Dec 2020 18:14:10 +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=lmGQgLGBhUH4rw9Xmb/x5bRo9Xb/oJgVLDZw+v+WbG8=; b=l4Gb5dTjEl4jTOb9r1drPUCMb8 EI+DUBz5nXgVqQ4+RIF7b9wFOcdEn35oPB7MFeCOb7VB1aSQ2leMN1lcd82W/egzjAo8NcH0A9QJF uzNNWQ4W6dTGzgm13wTb6XkYE7FNeEaGgafZn051CMIixzlkO1dwkXq8pr8sh4pKgD5PW8T0OLWM4 Lk2IXh1g22BWtZQoWLXIXXrYYh6hGsa1NzHMswvoerBibJq/IOx4zF2nXvB3PAkWlm6/Ll6B7N5Gq PRey6/BaANKDA+DyzKCUmcgqIehF9ghmad/JsbCQ6lklwoKB4mdCdbE5LbZJzr4F6wqsigaNzLHbd EF18VXjQ==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kn3yY-00080O-Qu; Wed, 09 Dec 2020 18:14:06 +0000 Date: Wed, 9 Dec 2020 18:14:06 +0000 From: Matthew Wilcox To: Jason Gunthorpe Cc: Joao Martins , linux-mm@kvack.org, Dan Williams , Ira Weiny , linux-nvdimm@lists.01.org, Jane Chu , Muchun Song , Mike Kravetz , Andrew Morton Subject: Re: [PATCH RFC 6/9] mm/gup: Grab head page refcount once for group of subpages Message-ID: <20201209181406.GQ7338@casper.infradead.org> References: <20201208172901.17384-1-joao.m.martins@oracle.com> <20201208172901.17384-8-joao.m.martins@oracle.com> <20201208194905.GQ5487@ziepe.ca> <20201209151505.GV5487@ziepe.ca> <20201209162438.GW5487@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201209162438.GW5487@ziepe.ca> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000186, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Dec 09, 2020 at 12:24:38PM -0400, Jason Gunthorpe wrote: > On Wed, Dec 09, 2020 at 04:02:05PM +0000, Joao Martins wrote: > > > Today (without the series) struct pages are not represented the way they > > are expressed in the page tables, which is what I am hoping to fix in this > > series thus initializing these as compound pages of a given order. But me > > introducing PGMAP_COMPOUND was to conservatively keep both old (non-compound) > > and new (compound pages) co-exist. > > Oooh, that I didn't know.. That is kind of horrible to have a PMD > pointing at an order 0 page only in this one special case. Uh, yes. I'm surprised it hasn't caused more problems. > Still, I think it would be easier to teach record_subpages() that a > PMD doesn't necessarily point to a high order page, eg do something > like I suggested for the SGL where it extracts the page order and > iterates over the contiguous range of pfns. But we also see good performance improvements from doing all reference counts on the head page instead of spread throughout the pages, so we really want compound pages.