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 45DC7C282D0 for ; Tue, 4 Mar 2025 12:50:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B71DB6B0082; Tue, 4 Mar 2025 07:50:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B21E56B0085; Tue, 4 Mar 2025 07:50:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C2DB6B0088; Tue, 4 Mar 2025 07:50:24 -0500 (EST) 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 7EF586B0082 for ; Tue, 4 Mar 2025 07:50:24 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2E7A8120924 for ; Tue, 4 Mar 2025 12:50:24 +0000 (UTC) X-FDA: 83183851968.15.EEBC2F4 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf12.hostedemail.com (Postfix) with ESMTP id 3986C4000B for ; Tue, 4 Mar 2025 12:50:22 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=IpH3WGRX; spf=pass (imf12.hostedemail.com: domain of jackmanb@google.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=jackmanb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741092622; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Za2+1iO7dL31cbQ2NJ7DZYtdHtY7Z5QXUzl1byI/FLw=; b=JqNcyqKNpCC+Ez/mQWhUcLSNRYy/zyVikOn5aQDIRtMIRwOB3MYHaYSoxMBKSkKLz/xOlC GK07nrvNul6s/Gh/bui/G2+eeTh96dMMfwHk0zolnrxQk7H7VEuVDcnFJQq7JKKygK/Cn8 U4i3ZZlfMzQQwzp5ATRTKossUtUZbRY= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=IpH3WGRX; spf=pass (imf12.hostedemail.com: domain of jackmanb@google.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=jackmanb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741092622; a=rsa-sha256; cv=none; b=VXfXI0Wz4AMg8A6v7uMISjWJzTlUBjWyjdpxRQsv871XEZgBVJu18HGyg0N7ioGOdk6mWU T+qYUzAgFeRFUgKamv99gCqIV0FW8/l1Z1iWcYZeR6MuadiGizLcbMBEMfT7QXI8V9WD6k /I6hQZ1arbPtxPWvj0ct4DZUO/j51Io= Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-43bca0048c3so42245e9.1 for ; Tue, 04 Mar 2025 04:50:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1741092621; x=1741697421; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Za2+1iO7dL31cbQ2NJ7DZYtdHtY7Z5QXUzl1byI/FLw=; b=IpH3WGRXH7NSh8XQ5/Ge1PAlzwMJJeMHStfTmJ1DOUR0AScO2LlAzgkkqyaWVC6++3 +NVpfcHQBo4HS6+QE0WTLibnaVOhz9oBpJFM8WWnq89Jm7BHZYotJxrvZHCbAK4G4pbW BSdZ9kxc9cPnVLvO1SRpId5gtROLy6UnES88Y/UWCCtx0KUX4/I1XfINaOzTVRcVaKzI YNLQQ/gYWSfyLGBB//6u2vUBKe1rf6Lf/eP8egpsQLDiFsCEeMLBSdpY4v9ybPR6DG1H M3JJ58nv3AX/nu0GWtIunBUMYI0s33E+VSWVN9yhWBSLMmx/hxshiRv+h36G39xnWBP1 jyGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741092621; x=1741697421; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Za2+1iO7dL31cbQ2NJ7DZYtdHtY7Z5QXUzl1byI/FLw=; b=uZaU6jC6Z/c5ZmdAjH9K2rVVpv0AGWJeCEBwoAXm/wpZr8ydjhZu6zn5r/A7yMGsoP 4ePQj5lEnsKPT2vhcqHKKvME7Eqn7PgDSJ3fcUIzYqqHe3ixCq9wefTYNFUAKYqrRGF9 IB9yN3c03lNSBFNU0T4w4EmURmZ7GpxnJX/pkiwEdWfXr4fI9n5O6nsPyBxC4f0aG9dn x+BtLJ8ptJb5CaUbIi8ZynAKzy7WkfKrLPEMKgNuNPHxdy726ZXP21Q0T8c/z37usGl3 9PK+eRmy5LZo6hI47jUV272+lry3PGQomy7c6P4uYoUjU2Od9RhDGjuSpsooaC5fYcMl 3WMg== X-Forwarded-Encrypted: i=1; AJvYcCW4ElknTI75EvdJvNLZIasFfwxbBMms0GxVRZBB7uI2kjBaqQ4TnxgBH+dt6r2mSSFlD3b7cTeNdg==@kvack.org X-Gm-Message-State: AOJu0YzNJNw3PFfvGu4nzT2PnxR1i0HJ+Wp4Wmu1R/AxAHRo1R1Clt6M gqOqBKLV/V9+sAKEldB3KimWT1fc96uIypGPMePWy7db3/nAsaaZiJyK+SBsUw== X-Gm-Gg: ASbGncuFTdzej1q9F4k5dJrSmCzu/iD5KZOwo6dAqlnxCtDQDJXviqA5V/m5UtC9squ NdXuLzyqkUDzuZ/cYfqGVoEi3eNALNZk276rX1f5Sju64cizYcHaEvS3jTeuVdFibWtaRKaVNsD oCRbpIC2+zZn9skYzoyNYEhCuj2y+e0x9Y6Wl5E9MYc5zDOgxWhNYEkDUkjNWGrjbcQkzuAWLty eFeppEt53ST8oA5SP74buUpIVHAOSIkIY5/EcrxnzZp7SH6qVIZslUDelZYts80vcU2ueNWkVVe 5vmgNzj2uuMsqQupFcl2/1il9tl2+IDIsxqn+ItRTtMKp78opUwR84OzVyJ9WQn6NnGmi46/UOh MvOQc X-Google-Smtp-Source: AGHT+IFhRnrV4mRUTOLd5oZokomaH93RHqi8VEcCLMksncmjcz/Y4Ytn4IeShC2SIGRJbJ1B+LxfNA== X-Received: by 2002:a7b:c386:0:b0:43b:b106:bb1c with SMTP id 5b1f17b1804b1-43bcb2aefd1mr1168965e9.0.1741092620567; Tue, 04 Mar 2025 04:50:20 -0800 (PST) Received: from google.com (44.232.78.34.bc.googleusercontent.com. [34.78.232.44]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43aba57145esm223586235e9.30.2025.03.04.04.50.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Mar 2025 04:50:20 -0800 (PST) Date: Tue, 4 Mar 2025 12:50:15 +0000 From: Brendan Jackman To: David Hildenbrand Cc: Andrew Morton , Oscar Salvador , Johannes Weiner , Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/page_alloc: Add lockdep assertion for pageblock type change Message-ID: References: <20250303-pageblock-lockdep-v2-1-3fc0c37e9532@google.com> <4d0f0bca-3096-4fb4-9e8b-d4dcdf7eeb92@redhat.com> <3e66875e-a4d5-4802-85b3-f873b0aa3b06@redhat.com> <0f120624-3ae9-4273-b349-b10d813a4e65@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f120624-3ae9-4273-b349-b10d813a4e65@redhat.com> X-Rspam-User: X-Stat-Signature: t9qc94ehfzutr4a1z3oxzfxwo89o7ahd X-Rspamd-Queue-Id: 3986C4000B X-Rspamd-Server: rspam07 X-HE-Tag: 1741092622-793830 X-HE-Meta: U2FsdGVkX18doHp6MWCMskCKYTK0krJ+vh5eMgnfQZCrCqjHHM44Nx3jtvllfdMbmmA7KO4WB5GN7X6qRw0OJYeyh5Y5BZSi3JEUZ0c9dSYYKuTvrdoHh4jFV4lqtqCzkXXMdBUUvDghY/M1utWclDK0icpYD/1kePl6roFlw7PcPD7aEZ4j+8tFnXwLEgnmScXjl40iD3IeXtREnn+cMWvVsDm4uSNxn67hOjuwZvzCymxiDqQjYh+DuJF4pEJFc+7WE3kBBTSqwbLPOcySt653Xf3HapwCEigL+tkASz7GGVJpoYIJi1ivjCK1uFvU0Q5Md3uaP9DDKWC/6Qk1T/Ijr8EjHcptXu0/zYfgHQogzy5MSpmIb5fP2cZVVhIKjGtTXAM2JigRAKhiyxK3MVSHwEnuFW5kNRqNpIDn38CJ/BEodUjiafaXCygDZKBik4uIMJ6ieFfPKYdBpPoLkUFVP5kEPAgTl0ZiyWmUQIzW9tWxWy4QEzJW+k/mTSsQhMjJbybWV8GZGI8VIRlD4KIklt2SKwnYOw67pfnz/5wOTBi3NxEFiQGsFQmjYv2LUut86P02qe75kmbsupVRNVDC6QNdQkSW+KLlzN0LT7+HpUxEf9r0HXqCzB/G6vTped1KZX0klNhk9feyi6CJloW1kjW0FbrNFIqQwYD5WhXTnBDYpOIlTqGWS3sSXqykemR//VHaQxUfOCSZDZyGBdHJEf6FzvUoMWhYWqEbFKf+B8hcdktLszoIRSPASUZhF1Fq5FS5pjs/sBP/fPFFr/nmsQKgua4AcymJ/x0naqglRheJSE0jLjFvMpMZaz7Ds5+ir0jtEySvQvzP49rJCXLdlwNhgHLHJhS68ZeR03g6qsv2bkGdIjfW9ywLRp+wS+54PSEt0EdiDmMbLN2l2qs0vq2sbe41yDxYvnNQ5yM17nKYchjX49bhUeWLLfyay901ZakhyFqxRLAl2+S GbsUKlYs TWKLeTJolFHBZNtrsvLOoUabixOqI04knTRibmnHU4tqHp2zGPdr4nVvf8cHrbVKZTidMRPgRSz9umffA4EFLe8C1pHWIAHvbDISh1/nsnbhobhPk7h92vRMPYvBL0t/+LSxopiCfr6+D+K0ICObdHhfVVE2DXQhfczYwsOO7NmelQJZ9EmfCtsqOcAJy15o5RvxQYN7I1gnV2u71VMFrxU1DO8I8LpaCXDqJGFVEmVkzf3m9EAzWPqf1AJir98NBvygY8sLC2rjt8ZACkGmzlvluxuyfBlrOoaDbKUygakjpmY1bQVI6j/ip/tCogHpsVlpOdgaD8eQwAi20GSNnG9P6o5fIUR6XFxqmdniShoc7uG4x+4B8LCXQdbU/xT2MOO8ZSx8kxIfHQaMVlZXWj6FXAQ== 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: List-Subscribe: List-Unsubscribe: On Mon, Mar 03, 2025 at 06:06:12PM +0100, David Hildenbrand wrote: > > > But I am not sure why memmap_init_zone_device() would have to set the > > > migratetype at all? Because migratetype is a buddy concept, and > > > ZONE_DEVICE does not interact with the buddy to that degree. > > > > > > The comment in __init_zone_device_page states: > > > > > > "Mark the block movable so that blocks are reserved for movable at > > > startup. This will force kernel allocations to reserve their blocks > > > rather than leaking throughout the address space during boot when > > > many long-lived kernel allocations are made." > > > > Uh, yeah I was pretty mystified by that. It would certainly be nice if > > we can just get rid of this modification path. > > > > > But that just dates back to 966cf44f637e where we copy-pasted that code. > > > > > > So I wonder if we could just > > > > > > diff --git a/mm/mm_init.c b/mm/mm_init.c > > > index 57933683ed0d1..b95f545846e6e 100644 > > > --- a/mm/mm_init.c > > > +++ b/mm/mm_init.c > > > @@ -1002,19 +1002,11 @@ static void __ref __init_zone_device_page(struct page *page, unsigned long pfn, > > > page->zone_device_data = NULL; > > > /* > > > - * Mark the block movable so that blocks are reserved for > > > - * movable at startup. This will force kernel allocations > > > - * to reserve their blocks rather than leaking throughout > > > - * the address space during boot when many long-lived > > > - * kernel allocations are made. > > > - * > > > - * Please note that MEMINIT_HOTPLUG path doesn't clear memmap > > > - * because this is done early in section_activate() > > > + * Note that we leave pageblock migratetypes uninitialized, because > > > + * they don't apply to ZONE_DEVICE. > > > */ > > > - if (pageblock_aligned(pfn)) { > > > - set_pageblock_migratetype(page, MIGRATE_MOVABLE); > > > + if (pageblock_aligned(pfn)) > > > cond_resched(); > > > - } > > > /* > > > * ZONE_DEVICE pages other than MEMORY_TYPE_GENERIC are released > > > > memory-model.rst says: > > > > > Since the > > > page reference count never drops below 1 the page is never tracked as > > > free memory and the page's `struct list_head lru` space is repurposed > > > for back referencing to the host device / driver that mapped the memory. > > That comment will be stale soon. In general, ZONE_DEVICE refcounts can drop > to 0, but they will never go to the buddy, but will get intercepted on the > freeing path. > > > > > And this code seems to assume that the whole pageblock is part of the > > ZONE_DEVICE dance, it would certainly make sense to me... > > Sorry, I didn't get your final conclusion: do you thing we don't have to > initialize the migratetype, or do you think there is reason to still do it? Sorry yeah, I was concluding that I don't see any reason to set the migratetype here. But, given I didn't even notice this code path until your review here I am not feeling too confident about changing it. I can try to stare it some more and hopefully some courage will build up! I probably also need to find a way to run a system that uses ZONE_DEVICE for my local testing...