Message ID | 20240409192301.907377-8-david@redhat.com (mailing list archive) |
---|---|
State | New |
Headers | show
Return-Path: <owner-linux-mm@kvack.org> 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 8A674C67861 for <linux-mm@archiver.kernel.org>; Tue, 9 Apr 2024 19:25:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 20BD86B00A0; Tue, 9 Apr 2024 15:25:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BBED6B00A1; Tue, 9 Apr 2024 15:25:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 084066B00A2; Tue, 9 Apr 2024 15:25:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id DBFF26B00A0 for <linux-mm@kvack.org>; Tue, 9 Apr 2024 15:25:04 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 9776FC04E2 for <linux-mm@kvack.org>; Tue, 9 Apr 2024 19:25:04 +0000 (UTC) X-FDA: 81990971328.16.93A4BEB Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf09.hostedemail.com (Postfix) with ESMTP id E2E2C140015 for <linux-mm@kvack.org>; Tue, 9 Apr 2024 19:25:02 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Mj8euJmy; spf=pass (imf09.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712690703; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6rnCGH1F82LpMt5YjVvPZTK3t5BGo8uUqDhbNYCO1mM=; b=nP5mrF32YmDaAHjD1kr3QpHTBz7mbuoe1OHnoXk8JkBrfR1vqrFVQVJX8UwTm/T825CJSS kNJyoEH1BFIyrWPZYSCGvVKGFJ5DhI5HGJkeyX7ZwapDh0UBYJ6TCrqbaVaRXvwhoC1it5 iUQQj8/UeoHI57Kr7IY5DVQOPUfhkj4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712690703; a=rsa-sha256; cv=none; b=dqJXTrBLf0fnHYNn7L6/tLMsRJr6Zpkq82+XMmMkL4o0qrkJWpODMQNuVJ7TpJtp7BR6pE ifiDdjHdOhkf2EHvsrGEhmpw3GUqL1UYF0pTMBCkIRLMbxsW9fhKgJrOIKWEcaBCm1YTcJ FDkXlP0NCpidBtlD5K6suoQ9u21MJpg= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Mj8euJmy; spf=pass (imf09.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712690702; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6rnCGH1F82LpMt5YjVvPZTK3t5BGo8uUqDhbNYCO1mM=; b=Mj8euJmyRbkqnGtXpMHf65w26Z9md3rt3ifAm+BoSVIrjYQjF6/TWfFWxPaOn/O3w2vUo6 AenTeskHeiXKQMCTVVBG861ko4x+M35IMY9vNL5kIr91Fg82VeXT4va2j8p22Jr6YxvXmj 3Vi/Slmvart/Rh0cNZgL2NHKU7Zq9AM= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-195-HVcby02FNvy6GQIyoWw54g-1; Tue, 09 Apr 2024 15:24:57 -0400 X-MC-Unique: HVcby02FNvy6GQIyoWw54g-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6D86429AA392; Tue, 9 Apr 2024 19:24:56 +0000 (UTC) Received: from t14s.redhat.com (unknown [10.39.192.106]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0A40740B497A; Tue, 9 Apr 2024 19:24:42 +0000 (UTC) From: David Hildenbrand <david@redhat.com> To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, linux-doc@vger.kernel.org, cgroups@vger.kernel.org, linux-sh@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, David Hildenbrand <david@redhat.com>, Andrew Morton <akpm@linux-foundation.org>, "Matthew Wilcox (Oracle)" <willy@infradead.org>, Peter Xu <peterx@redhat.com>, Ryan Roberts <ryan.roberts@arm.com>, Yin Fengwei <fengwei.yin@intel.com>, Yang Shi <shy828301@gmail.com>, Zi Yan <ziy@nvidia.com>, Jonathan Corbet <corbet@lwn.net>, Hugh Dickins <hughd@google.com>, Yoshinori Sato <ysato@users.sourceforge.jp>, Rich Felker <dalias@libc.org>, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>, Chris Zankel <chris@zankel.net>, Max Filippov <jcmvbkbc@gmail.com>, Muchun Song <muchun.song@linux.dev>, Miaohe Lin <linmiaohe@huawei.com>, Naoya Horiguchi <naoya.horiguchi@nec.com>, Richard Chang <richardycc@google.com> Subject: [PATCH v1 07/18] mm/memory: use folio_mapcount() in zap_present_folio_ptes() Date: Tue, 9 Apr 2024 21:22:50 +0200 Message-ID: <20240409192301.907377-8-david@redhat.com> In-Reply-To: <20240409192301.907377-1-david@redhat.com> References: <20240409192301.907377-1-david@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 X-Rspamd-Queue-Id: E2E2C140015 X-Rspam-User: X-Stat-Signature: 13tp71epbkzz46q4hju1shiw6newxajo X-Rspamd-Server: rspam03 X-HE-Tag: 1712690702-433325 X-HE-Meta: U2FsdGVkX1/Qltm6ID6lAp8aDQDySbvu8D1uLI3+FWhNywko5/huLN4rP8+Rxsbl1vtVgAi8ebGsev7aeA86jHKWwcDlPVzmC8iISx54tobJ0dguxFZDCc4pm9DgVJR7WSfj7eXKGy+yphbhAGAtVo8GfB2ArxcKLocci6MVxszdtHNWvkaD3G3LO5c5wVybnZCVxTTteHelJJJE9eXKooozfa+5kBQz4suVrSjbcVeWR82EdqdqCeovwCE19oNFIhed68h5LXMEBU5alcTYHJnQcxXlAB32BqN8iKEmPoYb+/ejOJI9tXaUg885vcG2lAFrOSuFCfhhEsRiENrVA3/Uo8QiBoZxQ1yFCZX07Ivay6Ikkn8sKsfhC5ZWpQRahUPqrF35siekBEXqt5ntwAF92js3eFbJuJNi96ahE7kUSJ06febqBkJc52PR9lSl5nwG74m3fv41Rw9LFJNTGw8ewaQjDiFm921OBwbhKs1mg1Txj/rYaJm5EPLK29D/PQWQAD4omI6yfcvCvbMhrjS+D7dmX0Yz0rd+n9zxFs9lMNX0dZS3g6X/7w3rgcjeK/LoPADvYNDYtcSJ1BS+QAfXXXjZSQKnS0Fhl+z50527IA8dnozRDzLsr0JjBN3WXs4u0IRRC0v15uWncpW3x6NUeLKRKgbsrSII2Eq7yN2ejxzjWSWvw2fv1ySrG+HHUScVJBsFStQ9tW254krXrqHXUgEwqJb3Xn0n4/C7777oYSpYWOrTjtHWvWNJIGdqG2GZjzrY8xTNaLtRRMa6sorCPH2tvbn5a+n0ObBYVHaO/PVzslVRSMUiKvuezKoksYzZFP8NZdgYsMPhgZd9ZDc/KNer27MiaRHvri9eOKuPuwkEtXwOV7a2VT+TetVpdq0jy1lrFVs/VlLmVQ8cuUvj6kYoTj9x+CyU83t0Lslr6C5XKM6XeWkUiYotDRQ8w07eqv2rB2VBW3sHM0z h//CWvYR 1Kz91S+aeE/gVGcTTRIeoQKTQot0AsrgTn5OrR+r89ISrwAw2nE6avvgfvJQjxVJ4lCJlgHFpE4Tj8Qucpz0V8+yglMuwGBoch82Ixo8PlLXZEx9wIUdynykJgTSI7GTw/fnBpnWtrTXtWdWnQVvsE+Yfwf734ohVZ0mof/HtuAqjdX25CxHd8I8eyd01ti8RF4wUpTTpIH67AugFjXBV/4jrPGFm0VXWvL3b 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: <linux-mm.kvack.org> List-Subscribe: <mailto:majordomo@kvack.org> List-Unsubscribe: <mailto:majordomo@kvack.org> |
Series |
mm: mapcount for large folios + page_mapcount() cleanups
|
expand
|
diff --git a/mm/memory.c b/mm/memory.c index 78422d1c7381..178492efb4af 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -1502,8 +1502,7 @@ static __always_inline void zap_present_folio_ptes(struct mmu_gather *tlb, if (!delay_rmap) { folio_remove_rmap_ptes(folio, page, nr, vma); - /* Only sanity-check the first page in a batch. */ - if (unlikely(page_mapcount(page) < 0)) + if (unlikely(folio_mapcount(folio) < 0)) print_bad_pte(vma, addr, ptent, page); }
We want to limit the use of page_mapcount() to the places where it is absolutely necessary. In zap_present_folio_ptes(), let's simply check the folio mapcount(). If there is some issue, it will underflow at some point either way when unmapping. As indicated already in commit 10ebac4f95e7 ("mm/memory: optimize unmap/zap with PTE-mapped THP"), we already documented "If we ever have a cheap folio_mapcount(), we might just want to check for underflows there.". There is no change for small folios. For large folios, we'll now catch more underflows when batch-unmapping, because instead of only testing the mapcount of the first subpage, we'll test if the folio mapcount underflows. Signed-off-by: David Hildenbrand <david@redhat.com> --- mm/memory.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)