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 EA6A9C02182 for ; Tue, 21 Jan 2025 13:33:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 254E96B007B; Tue, 21 Jan 2025 08:33:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 204CF6B0082; Tue, 21 Jan 2025 08:33:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 07DC86B0083; Tue, 21 Jan 2025 08:33:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id DB0E16B007B for ; Tue, 21 Jan 2025 08:33:08 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 80881C093C for ; Tue, 21 Jan 2025 13:33:08 +0000 (UTC) X-FDA: 83031550056.19.2F9B222 Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) by imf25.hostedemail.com (Postfix) with ESMTP id 7C268A000B for ; Tue, 21 Jan 2025 13:33:06 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Llq5SG/I"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.51 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737466386; a=rsa-sha256; cv=none; b=c9upjQ/dqhJiNqElTs6pEdB7knBuKGd6X19KBjdCLMZaX3owLSEnxCZpskhq9JQxp7JkMT vQXIQEcUJqSzNFf3DkavjkEjZ5muVhnV1NM4FvgXMUEAfRoUr3VmipC7eRyo6o9fvlW682 CPl1qDBt7vvtC9KbMC5n8jGsRadpUOg= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Llq5SG/I"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.51 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737466386; 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=A6YQZcvL/hb1ak8eMBU8kvwQ3lsLC5xoPU1usRdV2ko=; b=V+sX41fpvwVqK+g3JbY+CfDufGpRKVIApQMH/R2CC7HuDzPpCHAiLLSajavhErLtGwCXbC bUWS9WPvrV0IQktCnniVOhvWX8T977hJTBmoFqAta3iPcrjX0I4FVtyaIsptxxgYxhEAxq 86wArQaT4M39i2G6srDHO+CTlq2EQe8= Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-53e3778bffdso5925341e87.0 for ; Tue, 21 Jan 2025 05:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737466385; x=1738071185; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=A6YQZcvL/hb1ak8eMBU8kvwQ3lsLC5xoPU1usRdV2ko=; b=Llq5SG/IONiyuNjES71FxgC1b22SvtXJktl2Bi7oahnCswduzc5ZxUT92N4dCHNy9l 6Q05j4/AWStaRaSWUn6dNGUszQ0GL0AdI/lCr/ds/5M6D5uhZGi7UBhUxFJQ8CI7rg3i 79PBRSzTjAbnVXbDZYoDhyX32LJ/bHTZWo4u51Biqef5pHW+lGZbjtiZc5DSxBJx5V/s 5YZxGuwhm9psU086FTJgWcGiTjZ4wUSxkJ/3JAshSVxaz1B1o/wJ4EePa9S+DsWsGQ68 y5u6WLXSOvDxY6v+CKKfF9CnJ24HBhUw3JyAJ+tFw2MjKxVIxDwg7gV48UuGbxuSy8mQ jBrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737466385; x=1738071185; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=A6YQZcvL/hb1ak8eMBU8kvwQ3lsLC5xoPU1usRdV2ko=; b=QVMMH+/6/lIyneFQt12fjdV54AiHwg7z6i8/4cw2V8QEeZiLKoyYaykGrbMIphsnVr kRIwbKiBMtMboraP+ef/YJVdSu3spAlEI+m2iLq+kKJLA2Y3k3s7JuM36+B02ySrwTO5 8bGJ+TOf6O+Z63EwjZlG8S6Wjz8LUGTy9SnYDzvSSFcPR4amm680WVaX6Lhkj5uYClCs 880ZPSpZDh7rmlLTXAXBzIUrcd0U96OfVrUJ0nCm9yzH9EiOfu98lrOqIgVdbTR0lmte yjDGDxPlRGiqyHDrDAR2oHU4BVWS+xnfyDg1JSlgCrj3+lUkpWdTpNbhfqettXIa9Qta aYpQ== X-Forwarded-Encrypted: i=1; AJvYcCWoZiceEA0fml2QK0Wy5al9jn493LsAyQLBrOIQVlTi4jOBpB3WsvoIDAlVNpSATeocBJgwRBdOJQ==@kvack.org X-Gm-Message-State: AOJu0YzpqhPOGlNNTNEzoIBRlrlNWaDVJCUShFIbRoMN/wqdcwX9wGQD FJ8It7w66HacW6h6LbKGYVusJ2xbzFiygY+lRJJiozWAxeO90SQeWiD3ig== X-Gm-Gg: ASbGncuIirpt+NYPgEw6MnyMrNKqx1d24zghuYjea7sojUxsMUrcY1e5UC5oJixb2JE QxjfBG9VlHeSvb8Kas14LFt3BuTgxmZjZHV+GqUe+7ZD55OcX6LeydpTFNGBrl2k8c0tKsl8vza 925JtZbzKWcvazsMzYy77k+n8tOLgCtLR6UM1LwY1DxoEEMMMj0z25Bo6l4+QvzRgJExfictzb0 624xHZVYn7/auqF/0d+phsj7dvDacfUPPZv4Yd1a1QPZKXTactXZMxeHWW4snxCyDHlbA9Fc25y vH3LvTz4CLniP/RlR0QZ++yN X-Google-Smtp-Source: AGHT+IEWRgo+ReUKAkJ9PkPVROxv9CETjK2Gy5AIbsrK2I/+SsvbCKgDeeAoWpbEioPsZ5Zd8p90HA== X-Received: by 2002:ac2:5541:0:b0:542:2335:c43a with SMTP id 2adb3069b0e04-5439c246321mr4253597e87.21.1737466384231; Tue, 21 Jan 2025 05:33:04 -0800 (PST) Received: from pc636 (host-217-213-93-172.mobileonline.telia.com. [217.213.93.172]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5439af7914esm1849117e87.254.2025.01.21.05.33.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jan 2025 05:33:03 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 21 Jan 2025 14:33:00 +0100 To: Vlastimil Babka Cc: paulmck@kernel.org, Uladzislau Rezki , linux-mm@kvack.org, Andrew Morton , RCU , LKML , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Oleksiy Avramchenko Subject: Re: [PATCH v2 0/5] Move kvfree_rcu() into SLAB (v2) Message-ID: References: <20241212180208.274813-1-urezki@gmail.com> <17476947-d447-4de3-87bb-97d5f3c0497d@suse.cz> <6fb206de-0185-4026-a6f5-1d150752d8d0@suse.cz> <5bb80786-220d-45d2-bd35-51876df4203c@paulmck-laptop> <55931fdd-1d5f-4ffd-8496-fe436171dee2@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55931fdd-1d5f-4ffd-8496-fe436171dee2@suse.cz> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7C268A000B X-Stat-Signature: xtjfa43fhuizsciibrm3jer1ya8e45so X-Rspam-User: X-HE-Tag: 1737466386-456576 X-HE-Meta: U2FsdGVkX18Qoq2cxQfbG1aKXR4nhnRhd98grHIWjroP0XuOZf3oZPq5NNC+EtitUhUFhIihluZc/VnBVqMThuSSR8dzJO5WfPjmr1v5SGrZ4F5h2WRNrboddE6ve/CR2M6TqJd1TpMuhKuHSST3ag8KwjKlSWWgZeLvlLT50WDBpcsD49RXuCvWBzaA5in4rCXG/EmY/60GbzOZx4QLfxdJtcsnNHF74oq8IjgraAtuflMaNzG5qGos1Bb9FKUclcjCiwBEc3PQFXlM1C+XCNn7fwPXNkl843BO0w+x0njeju2qVfj1XUHpYblNm5B7IppteWpJ3sxjlOEFUCYDPvIVH/1FxPxPdlDYQF9qqFQIKXxk8UEs81Ey9xCrd/BV1gCE456rKEt7E7avaBmIyGoU/1i70Nrzr+49aAhpmBEjyP6b08OawBZkgMLGQqJxDbMao2eb877yyDIMSSW7OZ5nHDgRBlEQL0cZgELjLzKs6DUC+h6DofuJA1DjNoDIyq5zAFJCU8U7zf/J+LscCcCBG/kY99MAdeFkkHU6Y8HhilJf8R/eFzRK7PBST3HT1BSFvJCUOByo/FYygA2BAUqSfHEvOYqmI001fTvb2pKQeni6r0K7UIDucDRLDbi4ru6HywgQ4BUQErgIBzocUzwInatX5FhEIICNHicV5H6DFFSnrSfHg91mQfPuqpVk7zsmwzhSIV3q9iIZzhkyJHLmm6H8Nak/Qwa1Dff1AQ0H0mMa5jzdL+aPJgVO5lOWs4uM0/kVAtdhe7PckErstQOJNGUF7RMyIVvou4t1ha4ATksXS/14Zlov8Zphkqc+TEYAF73UAsxmnJ+dM80MZO0mEpdhsG/6Zmdr3T7opWnxehUw8nRWEg3EtFl+faLTIn7Kn20iVRQvEHX9yLuqUzPSgXDlS4wZVHi1ydtXj+UzScqmXuugvJkwe8NnC/XkYFcxO7Ttme9cw5STLYL d/h2Z/t2 s4fsIcfMj5/Fx5t/O612Zb8ccxe3qMSTqy1KqhdIhy4WET+WsekSvNocdUyl1DMFdYDbshGKeGh1Xppe7FEE39jT0CBiozlDYHVTyj8TMRmAjttInupneckic5O16jDfTjNjT2fV6Bzz6PNb/WGoPt9wBSH5ZRU7HkjckOG/cibkWyzahP7+hjnxKy1bzFvGbkZhXm5tvn/2rDNSoJl/BjyMbv8DILNF5hGQk8gsXlDm36Jc/aYxez5DOO0H7hhGYO2Z51M1GhqmZ0AAb8ORmzXSXxCNKWo5ztYobLZ5M4QwR+SeJUCCAwiy7V1G5WiqtohiWBJna1/w4RqQ85hbuqBxiXo5hjkQq1WfhqnN8WxsyaIfzWjV5orKQG01Gkg7CuSsDnhcTdq299gvZapxYN7GJP1NCxXhaad0tJcMzqvTnFSmJ2A2NsYFWMc64elVULi1UY+bxDpYp7EwMVTDtyajof5GKmnyv27w1m0wNciusEsuA8gMFwHso5KIrZbvAedO7YO1drjNBcBs= 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, Jan 20, 2025 at 11:06:13PM +0100, Vlastimil Babka wrote: > On 12/16/24 17:46, Paul E. McKenney wrote: > > On Mon, Dec 16, 2024 at 04:55:06PM +0100, Uladzislau Rezki wrote: > >> On Mon, Dec 16, 2024 at 04:44:41PM +0100, Vlastimil Babka wrote: > >> > On 12/16/24 16:41, Uladzislau Rezki wrote: > >> > > On Mon, Dec 16, 2024 at 03:20:44PM +0100, Vlastimil Babka wrote: > >> > >> On 12/16/24 12:03, Uladzislau Rezki wrote: > >> > >> > On Sun, Dec 15, 2024 at 06:30:02PM +0100, Vlastimil Babka wrote: > >> > >> > > >> > >> >> Also how about a followup patch moving the rcu-tiny implementation of > >> > >> >> kvfree_call_rcu()? > >> > >> >> > >> > >> > As, Paul already noted, it would make sense. Or just remove a tiny > >> > >> > implementation. > >> > >> > >> > >> AFAICS tiny rcu is for !SMP systems. Do they benefit from the "full" > >> > >> implementation with all the batching etc or would that be unnecessary overhead? > >> > >> > >> > > Yes, it is for a really small systems with low amount of memory. I see > >> > > only one overhead it is about driving objects in pages. For a small > >> > > system it can be critical because we allocate. > >> > > > >> > > From the other hand, for a tiny variant we can modify the normal variant > >> > > by bypassing batching logic, thus do not consume memory(for Tiny case) > >> > > i.e. merge it to a normal kvfree_rcu() path. > >> > > >> > Maybe we could change it to use CONFIG_SLUB_TINY as that has similar use > >> > case (less memory usage on low memory system, tradeoff for worse performance). > >> > > >> Yep, i also was thinking about that without saying it :) > > > > Works for me as well! > > Hi, so I tried looking at this. First I just moved the code to slab as seen > in the top-most commit here [1]. Hope the non-inlined __kvfree_call_rcu() is > not a show-stopper here. > > Then I wanted to switch the #ifdefs from CONFIG_TINY_RCU to CONFIG_SLUB_TINY > to control whether we use the full blown batching implementation or the > simple call_rcu() implmentation, and realized it's not straightforward and > reveals there are still some subtle dependencies of kvfree_rcu() on RCU > internals :) > > Problem 1: !CONFIG_SLUB_TINY with CONFIG_TINY_RCU > > AFAICS the batching implementation includes kfree_rcu_scheduler_running() > which is called from rcu_set_runtime_mode() but only on TREE_RCU. Perhaps > there are other facilities the batching implementation needs that only > exists in the TREE_RCU implementation > > Possible solution: batching implementation depends on both !CONFIG_SLUB_TINY > and !CONFIG_TINY_RCU. I think it makes sense as both !SMP systems and small > memory systems are fine with the simple implementation. > > Problem 2: CONFIG_TREE_RCU with !CONFIG_SLUB_TINY > > AFAICS I can't just make the simple implementation do call_rcu() on > CONFIG_TREE_RCU, because call_rcu() no longer knows how to handle the fake > callback (__is_kvfree_rcu_offset()) - I see how rcu_reclaim_tiny() does that > but no such equivalent exists in TREE_RCU. Am I right? > > Possible solution: teach TREE_RCU callback invocation to handle > __is_kvfree_rcu_offset() again, perhaps hide that branch behind #ifndef > CONFIG_SLUB_TINY to avoid overhead if the batching implementation is used. > Downside: we visibly demonstrate how kvfree_rcu() is not purely a slab thing > but RCU has to special case it still. > > Possible solution 2: instead of the special offset handling, SLUB provides a > callback function, which will determine pointer to the object from the > pointer to a middle of it without knowing the rcu_head offset. > Downside: this will have some overhead, but SLUB_TINY is not meant to be > performant anyway so we might not care. > Upside: we can remove __is_kvfree_rcu_offset() from TINY_RCU as well > > Thoughts? > For the call_rcu() and to be able to reclaim over it we need to patch the tree.c(please note TINY already works): diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index b1f883fcd918..ab24229dfa73 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -2559,13 +2559,19 @@ static void rcu_do_batch(struct rcu_data *rdp) debug_rcu_head_unqueue(rhp); rcu_lock_acquire(&rcu_callback_map); - trace_rcu_invoke_callback(rcu_state.name, rhp); f = rhp->func; - debug_rcu_head_callback(rhp); - WRITE_ONCE(rhp->func, (rcu_callback_t)0L); - f(rhp); + if (__is_kvfree_rcu_offset((unsigned long) f)) { + trace_rcu_invoke_kvfree_callback("", rhp, (unsigned long) f); + kvfree((void *) rhp - (unsigned long) f); + } else { + trace_rcu_invoke_callback(rcu_state.name, rhp); + debug_rcu_head_callback(rhp); + WRITE_ONCE(rhp->func, (rcu_callback_t)0L); + f(rhp); + } rcu_lock_release(&rcu_callback_map); /* Mixing up CONFIG_SLUB_TINY with CONFIG_TINY_RCU in the slab_common.c should be avoided, i.e. if we can, we should eliminate a dependency on TREE_RCU or TINY_RCU in a slab. As much as possible. So, it requires a more closer look for sure :) -- Uladzislau Rezki