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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F547C433EF for ; Tue, 28 Sep 2021 18:01:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B294861359 for ; Tue, 28 Sep 2021 18:01:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B294861359 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C879B6B006C; Tue, 28 Sep 2021 14:01:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C36FB6B0071; Tue, 28 Sep 2021 14:01:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD7CB900002; Tue, 28 Sep 2021 14:01:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0047.hostedemail.com [216.40.44.47]) by kanga.kvack.org (Postfix) with ESMTP id 9D4736B006C for ; Tue, 28 Sep 2021 14:01:53 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 42CE2182976E0 for ; Tue, 28 Sep 2021 18:01:53 +0000 (UTC) X-FDA: 78637750506.09.A8E8298 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by imf29.hostedemail.com (Postfix) with ESMTP id EFA8A9000673 for ; Tue, 28 Sep 2021 18:01:52 +0000 (UTC) Received: by mail-qk1-f179.google.com with SMTP id x12so8206897qkf.9 for ; Tue, 28 Sep 2021 11:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Hbv2nrTZWWGTP0zetuxX8JZfSvkOTIqxNDWscf8lqjM=; b=k4yeqVkRBZLOz8RVqZfB/X5go9d5P08x7DAbdDnxauKP3w8Ly9MWhcIHzduBQOXIv6 5T5FpLdhoYxRIYJWBMLnAJ7jOYyO3vy177E9aPa3GqGMao6G1SAoEYk2fyt1p3IWPBuw K1Anqfuu7NYgolRTn0AfvVNGspfbs0NRJ1sKcbA2uCFLvg5fZxKmQPdfUDYS23yyyQLB aLowg6jW72cG3PRtSZ6WOi2yuNJGa4STjmwpcX5B0gvtmcRhLASp6KxUB1QEMamXP1nY oA4t3c6XPhHyNRDddoMK+c2IK+nwFlv8bVPLD9Q944WafOhKBZ3mKMpllZ11Y9sQe7tM HxuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Hbv2nrTZWWGTP0zetuxX8JZfSvkOTIqxNDWscf8lqjM=; b=ftEUiwe99HH5Pw/hUKX/G5BW/UCeAPL9sYkDvUZXwHIk2uII5Z82s7nYyR5Sp2s7hM kj2sS01Yk1m5Tlyq8Y3GCKW6vTlj5yyjf3ltD30ue7Z6F722Gh3JXM41LyW92V3h9t7r 5oNT2Jf1T+oY3b8O7dCHLUdp1pLJEXnaGFMQMvJXek1/zeu/GBjlkw+myA4H1L7JBtuE 4mAU6WD2iMOP10haxEunKMRyNeDQnt0J4N3gATVNhIN5Di8Q76JG712EQGIuImSVFLig BRB+Iotx35SJYPJy+FlCQZRRgtwkdQtxCHihDZkarlA17LwrgZ/SjlehqxYYNbdKRRoU 0Zjg== X-Gm-Message-State: AOAM533DY1EEwGHPt8sgtQ9VEwnP7sp7MghyUTPjTCEd39Kzb4PnhZeP CCApcXyiKk9nYDt9cBzX5/foaQ== X-Google-Smtp-Source: ABdhPJw8PoqtCM9jEu0HEkGUTPOuB+K045ZQ+xnwIr++i1ps2Ma+Gi571Hezhn6PyiIq87siDpO+yw== X-Received: by 2002:ae9:eb8b:: with SMTP id b133mr1406067qkg.188.1632852112225; Tue, 28 Sep 2021 11:01:52 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-162-113-129.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.129]) by smtp.gmail.com with ESMTPSA id q184sm15663797qkd.35.2021.09.28.11.01.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Sep 2021 11:01:51 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1mVHQM-007Eis-Ps; Tue, 28 Sep 2021 15:01:50 -0300 Date: Tue, 28 Sep 2021 15:01:50 -0300 From: Jason Gunthorpe To: Joao Martins Cc: Dan Williams , linux-mm@kvack.org, Vishal Verma , Dave Jiang , Naoya Horiguchi , Matthew Wilcox , John Hubbard , Jane Chu , Muchun Song , Mike Kravetz , Andrew Morton , Jonathan Corbet , Christoph Hellwig , nvdimm@lists.linux.dev, linux-doc@vger.kernel.org Subject: Re: [PATCH v4 08/14] mm/gup: grab head page refcount once for group of subpages Message-ID: <20210928180150.GI3544071@ziepe.ca> References: <20210827145819.16471-1-joao.m.martins@oracle.com> <20210827145819.16471-9-joao.m.martins@oracle.com> <20210827162552.GK1200268@ziepe.ca> <20210830130741.GO1200268@ziepe.ca> <20210831170526.GP1200268@ziepe.ca> <8c23586a-eb3b-11a6-e72a-dcc3faad4e96@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8c23586a-eb3b-11a6-e72a-dcc3faad4e96@oracle.com> X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: EFA8A9000673 X-Stat-Signature: whz6f6capagomzjxbndjy71m8yykb9s5 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=ziepe.ca header.s=google header.b=k4yeqVkR; dmarc=none; spf=pass (imf29.hostedemail.com: domain of jgg@ziepe.ca designates 209.85.222.179 as permitted sender) smtp.mailfrom=jgg@ziepe.ca X-HE-Tag: 1632852112-585628 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, Sep 23, 2021 at 05:51:04PM +0100, Joao Martins wrote: > On 8/31/21 6:05 PM, Jason Gunthorpe wrote: > >> Switching to similar iteration logic to unpin would look something like > >> this (still untested): > >> > >> for_each_compound_range(index, &page, npages, head, refs) { > >> pgmap = get_dev_pagemap(pfn + *nr, pgmap); > > > > I recall talking to DanW about this and we agreed it was unnecessary > > here to hold the pgmap and should be deleted. > > Yeap, I remember that conversation[0]. It was a long time ago, and I am > not sure what progress was made there since the last posting? Dan, any > thoughts there? > > [0] > https://lore.kernel.org/linux-mm/161604050866.1463742.7759521510383551055.stgit@dwillia2-desk3.amr.corp.intel.com/ I would really like to see that finished :\ > So ... if pgmap accounting was removed from gup-fast then this patch > would be a lot simpler and we could perhaps just fallback to the regular > hugepage case (THP, HugeTLB) like your suggestion at the top. See at the > end below scissors mark as the ballpark of changes. > > So far my options seem to be: 1) this patch which leverages the existing > iteration logic or 2) switching to for_each_compound_range() -- see my previous > reply 3) waiting for Dan to remove @pgmap accounting in gup-fast and use > something similar to below scissors mark. > > What do you think would be the best course of action? I still think the basic algorithm should be to accumulate physicaly contiguous addresses when walking the page table and then flush them back to struct pages once we can't accumulate any more. That works for both the walkers and all the page types? If the get_dev_pagemap has to remain then it just means we have to flush before changing pagemap pointers Jason