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 931F7C02181 for ; Wed, 22 Jan 2025 15:04:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA5D16B0082; Wed, 22 Jan 2025 10:04:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E7CD36B0083; Wed, 22 Jan 2025 10:04:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF6786B0085; Wed, 22 Jan 2025 10:04:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id AE4E86B0082 for ; Wed, 22 Jan 2025 10:04:40 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 614D51602F2 for ; Wed, 22 Jan 2025 15:04:40 +0000 (UTC) X-FDA: 83035409520.28.8C2DE82 Received: from relay.hostedemail.com (unirelay04 [10.200.18.67]) by imf06.hostedemail.com (Postfix) with ESMTP id 0574D180008 for ; Wed, 22 Jan 2025 15:04:37 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; arc=pass ("hostedemail.com:s=arc-20220608:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1737558278; a=rsa-sha256; cv=pass; b=4IkMZOw0eSPxNXMWzuVjG0tk1VuPEsfVtnrzQoNn1bzBVmZ2JGzclpUL7sOmManJwAzLf2 DdCzYRX4golKk+SqJLAsLSN0JTDop9aKf1YlK1CFscLo5QEhp6k1mEhfEKF8rIqxKlP/uP wqTiCOtER3FeFWEkwvRgHJICBOmKK/w= ARC-Authentication-Results: i=2; imf06.hostedemail.com; arc=pass ("hostedemail.com:s=arc-20220608:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737558278; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=beq5Dw/Wj94v2uHKhR7RPB2XOGUho+A4hGE+uPW4pNE=; b=4ra7SeDf8DTDBOOjoPTUW5V0Tp2mItwKws5LRlpyNCovTUDkoZ3i9yPnw2EvBBTMcmsC6q q5/N+6kVlTQX5HUts2lmwbVTRnjdq7Vzi2RT3AI6a+FbsJQfQjVxgH+itfvkf28V/HMPur PJP6B2/DUJn+8m8hbj6MPtaleXwr4Sw= Received: from relay.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7D51E1A02B6 for ; Wed, 22 Jan 2025 15:04:37 +0000 (UTC) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 21FA01C6CF4 for ; Wed, 22 Jan 2025 15:04:37 +0000 (UTC) X-FDA: 83035409394.09.0A4A0F0 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by imf25.hostedemail.com (Postfix) with ESMTP id EBF21A006E for ; Wed, 22 Jan 2025 15:04:22 +0000 (UTC) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737558263; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=beq5Dw/Wj94v2uHKhR7RPB2XOGUho+A4hGE+uPW4pNE=; b=exRPztae4RmSHvlT2UlEbyjMr4wCCj9WbTuLAVbtKUjspIrmEBkZtLQOje3plBuhXbfJ87 62cbPqSmERREQL28DXFqKIxZvmSwCbtI84lXiVReQcLE147gDPMLPOW+r2r4g7Vl5U4kHA ekK4NchKq3SCfwv5OeepJBjenC6de40= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737558263; a=rsa-sha256; cv=none; b=yVuoqK91mSXvXXCUQPq8vJ52Lh3JVWVz7tqBoNmMrBadCmOgCnPHuiPUMaPwJVpzvI6XLy qWgwuJZKtaVsZj+SBY0Kwo+UdkIZXXXqSCtbt2lYt1o9tPye1XLhryTTQbK/3xYAN3af7k eIXYuqqXwsXd7Y/v8rmYaoK80MIUYaw= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b=LrTanZbH; spf=pass (imf25.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.128.48 as permitted sender) smtp.mailfrom=joel@joelfernandes.org; dmarc=none Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4361c705434so50883805e9.3 for ; Wed, 22 Jan 2025 07:04:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1737558261; x=1738163061; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=beq5Dw/Wj94v2uHKhR7RPB2XOGUho+A4hGE+uPW4pNE=; b=LrTanZbHtjEUg406KHyAm67TkHFTVHUzjX41C9/NOUMhrlbmmtbY+I3R2d74qURo86 rnjVGzmhiXKhn5lyb6aKajlK7KsWZWG69uhNMO3UvzxrbOwntHWsfUaoO7WeNbdP8Lyk LeAWV/rxa7aM2uKaCQto0rQVG0oVuFEivHCeQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737558261; x=1738163061; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=beq5Dw/Wj94v2uHKhR7RPB2XOGUho+A4hGE+uPW4pNE=; b=KIH/WPQVncC4b/E/7es7poqPLJ1+FB6kSOETe70V3MweU6QmQuJfBPRv2f+GoGjTln nGAOdoivLw2dV0TT5nYaXkafbYwkETGVQhdGCLW23txp4YUfBQrYkzQdhWpipr4k/Aqi BGUWKsuu+ne5H9fQBhxwVqecHlsDBSH4ChvZngbGXID5DkJcn2viOYH25Hv5KAXO2h9M 1tDJCUOyEQ1QGvH9CRfgZbWf2qBbTgFuQ6F2DzERAnstN1UH8VGdWSrOVyLZIZ2ExCub Mh1g8ZB3M4DsMPsaoBoQy1VFmMsp9L0/tO3sruP9MR9MKpgsl+iFXJmpfwfYtyXErScU lUEQ== X-Forwarded-Encrypted: i=1; AJvYcCW1HvpeaQdXbczmil6F9i9lcjXvkTQZ7SWi/4WJ6MILvhHcDWPOX4NRsE2qEP7xBUEOX9ITG/LoAg==@kvack.org X-Gm-Message-State: AOJu0YwlZjRl1ILEz3Sy5aXX2y89Tlj6UI8K3LPEwwEAW1e/kCkAWhZa 0SAg6TejUnerWKzOrCHrpQBu/A9q6Fm2DcuMCwzCRHc67/K76gMtLWEF/M59gwG/vCzzBoLgKQd 3Uxb/2lp1HZXlVBMABLbrLjLjifuzQee3W9LkCA== X-Gm-Gg: ASbGncuJaDm+WeRnWkC6pFYOrbGF9Sybm7CMjqtWExFf+YVzsZ+VUSbMpn/iJlNR9WR 1fIZBb1Z61oKz3UD9+/5qMjgF5w3uk5Ing4XatzOvIt+zdk3Q7+s= X-Google-Smtp-Source: AGHT+IFqYKI2yTM6/ViaX+n5Ncx78wzlkz5+ir+FuEzBfl0J6daloxJs836ifIXPV53CXeIJv4QLBSpADhXk9JtLJPI= X-Received: by 2002:a05:600c:510c:b0:434:a1e7:27b0 with SMTP id 5b1f17b1804b1-438913ccd4amr253225385e9.11.1737558261159; Wed, 22 Jan 2025 07:04:21 -0800 (PST) MIME-Version: 1.0 References: <6fb206de-0185-4026-a6f5-1d150752d8d0@suse.cz> <5bb80786-220d-45d2-bd35-51876df4203c@paulmck-laptop> <55931fdd-1d5f-4ffd-8496-fe436171dee2@suse.cz> <970317a9-0283-4eec-94ae-63056659d7de@suse.cz> <7b7b92a3-780e-4db0-a5cf-3e78d79587a2@paulmck-laptop> In-Reply-To: <7b7b92a3-780e-4db0-a5cf-3e78d79587a2@paulmck-laptop> From: Joel Fernandes Date: Wed, 22 Jan 2025 10:04:08 -0500 X-Gm-Features: AWEUYZnGXh-cy4Fy05kQi-BwXQRu3oDh4MuEhuimfq_L2MOxTXiEhCh0-kaIvl0 Message-ID: Subject: Re: [PATCH v2 0/5] Move kvfree_rcu() into SLAB (v2) To: paulmck@kernel.org Cc: Uladzislau Rezki , Vlastimil Babka , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-HE-Meta: U2FsdGVkX1/nrBOwWavLG8EYABQ5Y48QYFsyDy4NaZSj3JJGNtG7a+BBK5gMJVVEHxXEPvuHWwY9roEXdC6eEMFBSL69Dscp9NTo7w7akWcVylR4KyCyg8LBXJK9sLO8IrM5FWATO0I43lBp/hNeAYTWyiDlbnFd440m5vmlr5zFM9Akqh3KPWLCY7aMY6PzfqCFxLxrk0X1SY+FyLg2ub2cCIqkNWpYwUx57mN1ZFSE0wWfXcUHzYZkoXW75ikYcrzraf+d08iZWuiEWClVnBF9ectyCboKFIvpuz9C0vKhB5tNrLq5sl1uiDjU5+R1x4AUGL+Uw7hV3brRQi/VK9va3mOUN7+yA5ZrZ32H8ed6RY35NPXFrbQ1r7FxxypH6Gg5YfU97fM+p/7/QmIhcSy96dSJRrmOFGI4xFH8Y6c/VKA8s6qhyJqkzg7q+TGCuZM4Rs7TDFopMKQn8e3NVEMIPAl2euDyz/PoeJKsCDvYXg0TfkShAszMog+9Lvn7NPoIHHZOgvB5XM5B/2krRKSa4u4E5CSKcUItD5tgNkZospdzLNbxmzgwsffOinB2nDykeFaL3U6qSjHxWrSEe7CElscsXLgpintCG82F/JfQ7p+7oySemY74jcZNnwzgr7UvhcF9FsxBGhXppM1g/x4o7DNJYatn265pqWWmUf5sSe0q9C+A9tTEnkqI150T/ZSYyOxw49isnpxYJ3+Tfggp+7PEC+okSwrbho9vrzAbxwqKFUgSYvgoBzCWadpEgY3KzvzdvC+V0Sg/sBCE8/jzBk68gCennzRypWhC03XklrUbMJIQntioWe07u6+OFq84jxKVVcQ2Zm61ydTuHTwel0PDTc7bjgzaaHygWr1/2Dfm9cUfFMjoNLz/DgyJfh3VC+9bGzCDSleXNk0TaLsRMKZlQYMiR7sNQbHjyU7lE7cYHAHl+mMONvQkpDQlMkhvF6ddVmQfjRCxQxX StcCauR/ 7VerXtf/yOE4XUrl7LKlbvsFAbRjR2+l2hvijrQHFSbcEt3YHRgCNEGa3SvgKV/OGkLAf/NNvdzU08OJ2n67gJhvzPmMfkANuzIDIVB8xOOcrIvQzq0E0H5cw4sCG8WchBgt3D7IR2arQCS4hUgIoAVs2H0/fYpyC1QQtO2S+hIW82AF3dkbSrDAy5Aw4tLPAuxI9ceRc4JPk4TupWSSg21YFHMzffdM99FK/NWIrIbe6ELFjigo/w8tE1AoufvlBJh8ExMNKhKNeFupVpSFTyTkLj9ijreBIyNyPLCflicOatfJo5PTWNL1r18IZBlf5C2vcjGvicUqn65ARX1k4ZW5RKQ== X-Rspam-User: X-HE-Tag-Orig: 1737558262-19059 X-Rspamd-Queue-Id: 0574D180008 X-Stat-Signature: t7kgraz4n7hut6dxt6bumwam3fura76g X-Rspamd-Server: rspam01 X-HE-Tag: 1737558277-802314 X-HE-Meta: U2FsdGVkX1/KMIX1g/0m8tf6wQgHtet3zP++xDBu3pm8zFBFBAzYbQnVWvrDbe+lLy1cBsoSQ3wDzIi5xf8WJaqsflgAFJZGliSfp2eAGd9TTuwjdD/bb8pUVJT06Gj59arOZxKoWLc1Exi9Xtlt4v8rMw1JHfYqulJSZSwlwrNZQ0hQvI8icsa2/SlvDUOVMJ0E1RgghVlRnZY/rxw/+fVB7v1qO9kKtFw8jFjGGw27+cd0qE/D67RaANxlDlOLwVqbKNdpn3jwuOu9UpSO2hx/EYRKOOyYzuiauZbNXDfU+LM5lUPwKPhgXzi/5WGh0FiyJBX7W6EL0vdpd821BQqNzUClQFe+iHMebM8U3VxUC+sMJMVRzR8aYb4Eo1lGj0huBxdggrA4FBO9aoBBgcqvwM+SioagSBigwFafudCbvU7J5StS7eKBv0RKnTr0IDkyYGHxYNtTmoDGFXVBYMg6wzadNSdbtr/oDJEHc6oOGBMGyFOZBkZWrIpBLIAq1/6Y3I7zbD5UkCBM7rnooYlQ/vubht++kdunG1FM32FkaWAlGNBHY/PnpDBaljptEu3ggCUicLhGMYDZsiwWEpZto2C65KRzt0g9JhfvE2wXHNNlbH/iEiYVy1u9XrwfOxr67a8hdTTTAhuR/DNnHpG2W8gczXmo387QDWAkuekTGp/o/yq5EKX5aJPW2YhrPmYeCcOw6QXXFURJJy6SMGS5RFgwm+PD2XWvReOg9zYX+jDKcZg6oZ/jadNhjUeNsEyAGY+EZcNJdBDnWXiq7kpOxUcbrQvHUz+JhcpKbc13cJxy2sp/buchfmrHhN0Ga1tKUG9+t+vff1xo1iwUMYvGiCQHbmsSy+vaT21LkweQ6jKi87SR48EvfINIKsA+ycvsv+U6eDRP9JcTtQj634K8mcnzE5AFHH1+yWcbyAYlvWnQkPMUypQ5dv6iqdz+n6jM5uaNl8xv8cDfeSY b7Fe1xIi CyFsqV0mRPgi7VAIvf2TdqGgEqlRx/tx1chGWP2ssKdmCfCFcpHdflRYiUjq0hzVh8rie0mnOMo1IOJK/yxug5dv0ihXTRmWsYdlauIZd0/3wxvyrN6Mll/7J2l04lmfFIfD9Q6OWUnmM+pOveHn1gTkXmI2oSd6w26eqthkZbyPPEcGS9My9JjT372GF4RQx+BoNpl+it5fD28wH1QZkxQoVeA== 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 Tue, Jan 21, 2025 at 3:32=E2=80=AFPM Paul E. McKenney wrote: > > On Tue, Jan 21, 2025 at 03:14:16PM +0100, Uladzislau Rezki wrote: > > On Tue, Jan 21, 2025 at 02:49:13PM +0100, Vlastimil Babka wrote: > > > On 1/21/25 2:33 PM, Uladzislau Rezki wrote: > > > > 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 wrot= e: > > > >>>>>>> On 12/16/24 12:03, Uladzislau Rezki wrote: > > > >>>>>>>> On Sun, Dec 15, 2024 at 06:30:02PM +0100, Vlastimil Babka wr= ote: > > > >>>>>>>> > > > >>>>>>>>> Also how about a followup patch moving the rcu-tiny impleme= ntation 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 unn= ecessary overhead? > > > >>>>>>> > > > >>>>>> Yes, it is for a really small systems with low amount of memor= y. 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 norm= al variant > > > >>>>>> by bypassing batching logic, thus do not consume memory(for Ti= ny case) > > > >>>>>> i.e. merge it to a normal kvfree_rcu() path. > > > >>>>> > > > >>>>> Maybe we could change it to use CONFIG_SLUB_TINY as that has si= milar use > > > >>>>> case (less memory usage on low memory system, tradeoff for wors= e 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 sla= b as seen > > > >> in the top-most commit here [1]. Hope the non-inlined __kvfree_cal= l_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 o= r the > > > >> simple call_rcu() implmentation, and realized it's not straightfor= ward and > > > >> reveals there are still some subtle dependencies of kvfree_rcu() o= n RCU > > > >> internals :) > > > >> > > > >> Problem 1: !CONFIG_SLUB_TINY with CONFIG_TINY_RCU > > > >> > > > >> AFAICS the batching implementation includes kfree_rcu_scheduler_ru= nning() > > > >> 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() o= n > > > >> 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 #i= fndef > > > >> 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 we= ll > > > >> > > > >> Thoughts? > > > >> > > > > For the call_rcu() and to be able to reclaim over it we need to pat= ch 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 *r= dp) > > > > debug_rcu_head_unqueue(rhp); > > > > > > > > rcu_lock_acquire(&rcu_callback_map); > > > > - trace_rcu_invoke_callback(rcu_state.name, rhp); > > > > > > > > f =3D 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, r= hp); > > > > + debug_rcu_head_callback(rhp); > > > > + WRITE_ONCE(rhp->func, (rcu_callback_t)0L); > > > > + f(rhp); > > > > + } > > > > rcu_lock_release(&rcu_callback_map); > > > > > > Right so that's the first Possible solution, but without the #ifdef. = So > > > there's an overhead of checking __is_kvfree_rcu_offset() even if the > > > batching is done in slab and this function is never called with an of= fset. > > > > > Or fulfilling a missing functionality? TREE is broken in that sense > > whereas a TINY handles it without any issues. > > > > It can be called for SLUB_TINY option, just call_rcu() instead of > > batching layer. And yes, kvfree_rcu_barrier() switches to rcu_barrier()= . > > Would this make sense? > > if (IS_ENABLED(CONFIG_TINY_RCU) && __is_kvfree_rcu_offset= ((unsigned long) f)) { > > Just to be repetitive, other alternatives include: > > 1. Take advantage of SLOB being no longer with us. > > 2. Get rid of Tiny RCU's special casing of kfree_rcu(), and then > eliminate the above "if" statement in favor of its "else" clause. > > 3. Make Tiny RCU implement a trivial version of kfree_rcu() that > passes a list through RCU. > > I don't have strong feelings, and am happy to defer to your guys' > decision. If I may chime in with an opinion, I think the cleanest approach would be to not special-case the func pointer and instead provide a callback from the SLAB layer which does the kfree. Then get rid of __is_kvfree_rcu_offset() and its usage from Tiny. Granted, there is the overhead of function calling, but I highly doubt that it is going to be a bottleneck, considering that the __is_kvfree_rcu_offset() path is a kfree slow-path. I feel in the long run, this will also be more maintainable. Or is there a reason other than the theoretical function call overhead why this may not work? thanks, - Joel