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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18102C001DE for ; Wed, 2 Aug 2023 10:27:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7FF6B28014B; Wed, 2 Aug 2023 06:27:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7AED2280143; Wed, 2 Aug 2023 06:27:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 69DB228014B; Wed, 2 Aug 2023 06:27:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5CFAB280143 for ; Wed, 2 Aug 2023 06:27:32 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1372D140D53 for ; Wed, 2 Aug 2023 10:27:32 +0000 (UTC) X-FDA: 81078787944.09.1E8F925 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf06.hostedemail.com (Postfix) with ESMTP id 2B6E4180011 for ; Wed, 2 Aug 2023 10:27:29 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=none; spf=pass (imf06.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690972050; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1pEuh4bOr3hs/18lWEiEeDm/kWIIgEOYwFE92cSb7Sg=; b=atPOzxIgLXRom7v4kI9sNTRMFmucTn+FUYNeASycUc0ToX+hdJl/A1eG01rQhwCb4xIEhS ek7n5xSPOeMf6kRwmEA5L7FTf+epuZwJatEEbdnAR1Cr4HcK6L2qjtQydJZ9S6zZItvxFm qm815ejg40KGR9hgZoC3G8fekJMKpXM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690972050; a=rsa-sha256; cv=none; b=Ty89f6VNRKlFrdOjiDId0l4pxGO/FUhrbeq/GR+lqoR5c5Cuau8MVo3YK3e1+Plb+GCrBF tpAosimetEz5kxJOJ2dTUCOP9dr7KChUJjV/Ya3p+SkVHs2NDUMVeynPdUXqJXk0pRn7dK A/oa1j7YCvSy13woRcLkNA2hEwBGYPg= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; spf=pass (imf06.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 47B39113E; Wed, 2 Aug 2023 03:28:12 -0700 (PDT) Received: from [10.57.77.90] (unknown [10.57.77.90]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 64DCE3F6C4; Wed, 2 Aug 2023 03:27:26 -0700 (PDT) Message-ID: <3bbfde16-ced1-dca8-6a3f-da893e045bc5@arm.com> Date: Wed, 2 Aug 2023 11:27:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH 0/2] don't use mapcount() to check large folio sharing To: Yin Fengwei , linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, akpm@linux-foundation.org, willy@infradead.org, vishal.moola@gmail.com, wangkefeng.wang@huawei.com, minchan@kernel.org, yuzhao@google.com, david@redhat.com, shy828301@gmail.com References: <20230728161356.1784568-1-fengwei.yin@intel.com> From: Ryan Roberts In-Reply-To: <20230728161356.1784568-1-fengwei.yin@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 2B6E4180011 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: t4z1k4y7x1i1p8417nbf4gcus98wsxyc X-HE-Tag: 1690972049-904543 X-HE-Meta: U2FsdGVkX19NpqbKRU0VkuCjvxVrseuImy1+cpilrnK/7bincr4TQqoXMIUa8yVji7ulQJ6weX69RHfDDjUbX3HoBtMOrlqOsYS8XZwdvrSLH+lYU54Hxi4ESH9lscfMht5pYxpRbCKiBo6iR9PIGFQrGdtXoJHR6ZsoVYKTYsT0MaTFudgUhFDejFybK7bIp3RDmlukJc17THwLLEDB55z/2xcpD9SUrsr0gmtQsL9f/leTQELLpd4LCxiTvGyCY5PEJ9bwRmHIfYS/m9A04wvXxMY4mVqbA7Bmhg5tJiewAatIhUTKju99ZA+rWPNXxxAFvfV7jTIM4Wp4hv5FWAk4V+f/gAhbFxLEA473jdIuJ+9Hv0MDfUNdTyoFgWGqIqX9HvTEE1QVIirgP4aZx28qXZdZd43kF1cddxjJISHHqbL1MhILgaEkKBgb/MA9RcvEj3c4Omgu9hoEcVqmcTyUXrO/eMQiS+TRQi5+AP/b+xN9grKKB/WlRbyv5pfJb61TxMKCCxjsrMUGkJ1w+IYUy6bLJalbIR/2NGbenxTM3Ah4Pyz09mt5s84qpZCPnHGG2oZzb5GuykXcX58OF4p84tBWZ2ABuubGhY+UjQvN2GKLSP5j086eK6qJ7aUPiRIUcd1txAh/5JfiuI3ErvnxKZ4nWvUVef6oUfXZ2GqS9+GdM6vHG2jsxrW+hzJ5If/zs9BtjDCNMp9HBAOwS7B7nhF56tnq6vhkU+HgpzABPJGTfTAF+r4CcP3ustT7+ygVGkQ6oYfgQVNtOJ4iFsnMv+uSqD1rShuB8uKpJ44w1kjls7PqyrSnQCJXOQL2Z32M8B82Lr+vfrlb7jGY/ctFC2r5IUk9DyqNQYVx0yXH09NCpVTrpBs9J676djKSLX5yjoPILvSpYbfg3nMshzb/FcIe1NGNS8xBGz4NuF5OfBHiZ5cl6PVYVw+G297NtWzrgRQMAptCQ28ZpSi tOTnwe7f MBS178kIOKKQ0/yFW0606n+ETnro1+yFIfX0do0yXe4j6ZjYhGY4ycEPNxwUPX/z+Kv8K54m5A1YrrweqkzI0L2GwEqyUgl6TYJlwCfIip6BI9Aq8v9GzfZY+4wxpmUNfNYOCrdox8/CMY4yZqRLnyJh4neCExsk9/VuEftz1fd2VqvclU4gmlZbqeQ== 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 28/07/2023 17:13, Yin Fengwei wrote: > In madvise_cold_or_pageout_pte_range() and madvise_free_pte_range(), > folio_mapcount() is used to check whether the folio is shared. But it's > not correct as folio_mapcount() returns total mapcount of large folio. > > Use folio_estimated_sharers() here as the estimated number is enough. > > Yin Fengwei (2): > madvise: don't use mapcount() against large folio for sharing check > madvise: don't use mapcount() against large folio for sharing check > > mm/huge_memory.c | 2 +- > mm/madvise.c | 6 +++--- > 2 files changed, 4 insertions(+), 4 deletions(-) > As a set of fixes, I agree this is definitely an improvement, so: Reviewed-By: Ryan Roberts But I have a couple of comments around further improvements; Once we have the scheme that David is working on to be able to provide precise exclusive vs shared info, we will probably want to move to that. Although that scheme will need access to the mm_struct of a process known to be mapping the folio. We have that info, but its not passed to folio_estimated_sharers() so we can't just reimplement folio_estimated_sharers() - we will need to rework these call sites again. Given the aspiration for most of the memory to be large folios going forwards, wouldn't it be better to avoid splitting the large folio where the large folio is mapped entirely within the range of the madvise operation? Sorry if this has already been discussed and decided against - I didn't follow the RFC too closely. Or perhaps you plan to do this as a follow up? Thanks, Ryan