From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6FD7B320CAD for ; Wed, 11 Mar 2026 19:24:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773257064; cv=none; b=qi4RLoAYNxrU8bNutNpm/DkJVEqORvlnQIMVUdJ/ao+Ch2CSQHN1NPgC8f9vuBPX9EvU2YHH5OhUILKvGThY+jG5tP66UfLfz39f9QsnUdHKO1dG15UJQdx+2UjozslEr9Y0dtQQ3bW6XGCx++1a4LOZ6K7MihrdZNMMWFwtjjc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773257064; c=relaxed/simple; bh=4GC8+tOP/HpiA0uCCG26ea6x/MVU4D4Ky9o3JEo5mOo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nEdPg8BJuN4qMEHP1/bggG22o4MVpWdQ7qOq6kiUlCFpkhdqZRKDUZU/o+L1xMwYvtNORkg5sPVsJncA7jLwEFwM8XuqtINEVRQvqGca3jBT9RMJe7zK3wHW2JANU8FkyJeCiRKIEawSnbjWoH5UzkEmpoZbzn+QYEesw9y4RHk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=QYvkyqbo; arc=none smtp.client-ip=209.85.219.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="QYvkyqbo" Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-89a05955720so2904256d6.2 for ; Wed, 11 Mar 2026 12:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1773257060; x=1773861860; darn=vger.kernel.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=8U0uYARB35fXHTmG04QQVNwq76UNnAJXyOiaCIyb4bk=; b=QYvkyqboXRBUTQ1XQhmRoChpBwvwKpuy3S+yzuyn6rEOD8Nb4OVqZJ8qJbEgWBF7kA lRNHc65XdSXNLI5sE63DeJk8AxAFyBcDHMBol6AUgEWrbivZ5H0Pmg/DcGjst/4jIe9i uiKPqXqNNSJceAi4tl5DwskukaXD4oatU9lFORh/Wz3QHz/eCYQJCJ2pjRJHga7oW0rp VOZhsXsHtH6Dl23j3NJMd67sm0MzpIHKyX4yfhOHgIhTr480sbdX0jmbSKCsFs4apbvo kvq/xm+CfeIQ3QfW22DQjB1bdSeCHZzgX3SKFFqioaLXUERfaHQaRUg1wcqMO5S5vaZd TuYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773257060; x=1773861860; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8U0uYARB35fXHTmG04QQVNwq76UNnAJXyOiaCIyb4bk=; b=qHEoS01iTF5mNVXcBDONFV67wxwiuryjW+7q1Aleqf/P43PEy+qj5CB52jLXCh5ClZ uT3s3FpFO/5XRiTBfiSekFtZuKmLiuwcHcr8Z6o0pm4pjYFnLcygoZK6QARY8TwaiXyK eILw0AuyBjmATgV0nn+RYnZfARLDBcuGZ+cYuItN3e+VkjDaOKBsyjfc2rMAHGg8Cs3e 5g2l5ztYMEODp0yG6QNT+xyS7quBk1ZKT+RILalLgokhxZHNT99S3yRAljSbFPD3mLwD rn3ZoUkWg1tN+EKFmd8HPcKymZyVqFH60OJtX7zHcx/jpx0XmifD+QU3ivi3gTTkOaSp +5lw== X-Forwarded-Encrypted: i=1; AJvYcCVA7T0tSK86P2unuZCN3GlX/W43MlnRR//BVZHCXDZhPB359gTL/QrgLkrPMG/RLiL4sNX4a9VZE1OtgDU=@vger.kernel.org X-Gm-Message-State: AOJu0YwDbcBU9oUnkTFM1zT7KOfgnJ1wG2q07UbYO1TufvQAxBotyv3A tOPBU8J3U2yg6S/Un8aY4crxESeZvHV6MlITEj5s7f2KjSKyrFjAkANIhtuqS//nqWs= X-Gm-Gg: ATEYQzwCSsDqhzGZ/hmNZn0dZn/IUKGVZyEYt+Um8ZYHRCLq4xZBhJv95M9XKukmw10 ZlSYjJT5uuUArUHWoIyC5YqtpcGdTw35h9bLA7wvWOVJ3sU2/36GzgMXIxd+VduHjqqspsesyUY ysFn3GCTAJ4xATkYXxdXyFKHSSREwZ7u6zgbsfu7Z7FXnHAB2reUe0xax3dTrFBFLTpzL2/Cbie vF5xmU7ePqUx1J0N/+XSkOlPEg/v6JocU/OGyNIYmBZ8Gap18W8ndJq3uco1PNBD/rgWKIEQg+e qCjQDT2n49SU5p2slvnMZ/LSy7Pz3QWCA1qONiTNXzqe0qYRFdazM4do1Lgi/goN6KEibm3GKbO nyHMR8UJ1nMotbjKfviaILXANy9x1+pxwopjv0YeBnXAFcBrs9SEHxOfV1rWGcv6+rJO7QW8oVm TBhb1XnCeLRMEsBL+q5zheyQ== X-Received: by 2002:a05:6214:2305:b0:89a:717:1e48 with SMTP id 6a1803df08f44-89a66ae1ce8mr47665266d6.58.1773257060159; Wed, 11 Mar 2026 12:24:20 -0700 (PDT) Received: from localhost ([2603:7000:c00:3a00:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-89a65cfc409sm20026086d6.35.2026.03.11.12.24.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Mar 2026 12:24:19 -0700 (PDT) Date: Wed, 11 Mar 2026 15:24:18 -0400 From: Johannes Weiner To: Usama Arif Cc: Andrew Morton , David Hildenbrand , Zi Yan , "Liam R. Howlett" , Kiryl Shutsemau , Dave Chinner , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: switch deferred split shrinker to list_lru Message-ID: References: <20260311154358.150977-1-hannes@cmpxchg.org> <050ce5bd-4725-468e-acaf-7fca72b84d06@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Mar 11, 2026 at 01:42:32PM -0400, Johannes Weiner wrote: > On Wed, Mar 11, 2026 at 08:00:29PM +0300, Usama Arif wrote: > > On 11/03/2026 18:43, Johannes Weiner wrote: > > > @@ -3802,33 +3706,25 @@ static int __folio_freeze_and_split_unmapped(struct folio *folio, unsigned int n > > > struct folio *new_folio, *next; > > > int old_order = folio_order(folio); > > > int ret = 0; > > > - struct deferred_split *ds_queue; > > > + struct list_lru_one *l; > > > > > > VM_WARN_ON_ONCE(!mapping && end); > > > /* Prevent deferred_split_scan() touching ->_refcount */ > > > - ds_queue = folio_split_queue_lock(folio); > > > + l = list_lru_lock(&deferred_split_lru, folio_nid(folio), folio_memcg(folio)); > > > > Hello Johannes! > > > > I think we need folio_memcg() to be under rcu_read_lock()? > > folio_memcg() calls obj_cgroup_memcg() which has lockdep_assert_once(rcu_read_lock_held()). > > > > folio_split_queue_lock() wraps split_queue_lock() under rcu_read_lock() so wasnt an issue. > > In this case, the caller has interrupts disabled, which implies an RCU > read-side critical section. > > That's also why it's using the plain list_lru_lock(), not the irq > variant. Same for the lruvec lock a few lines down. I followed the > example of none of that being documented, either ;) > > How do folks feel about a VM_WARN_ON(!irqs_disabled()) at the top? Okay, lockdep actually does warn. rcu_read_lock_held() is explicit and not appeased by implicit RCU sections. Paul pointed me to rcu_read_lock_any_held(), which we could use in obj_cgroup_memcg() to suppress the splat and permit implicit RCU. Or we can make rcu_read_lock() explicit in the above code. Any preferences for how we want to handle this in MM code?