From nobody Wed Feb 11 18:23:13 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D6DDEC77B6E for ; Wed, 12 Apr 2023 09:14:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229829AbjDLJO1 (ORCPT ); Wed, 12 Apr 2023 05:14:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33004 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229735AbjDLJOV (ORCPT ); Wed, 12 Apr 2023 05:14:21 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C1121726; Wed, 12 Apr 2023 02:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1681290860; x=1712826860; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZCBfmX7VH4OWEyLOXzDSLuNt5/rJ6JN/8xJdJW2Ie1c=; b=Pu3JdxMxJ6AzdjAV7ytQ2YAxc5sGuSKIy+WfL27sRUfIhZmdpfy9qU2a m4NB3gSOL0je+WRYUVSdih48vLdWJWljI6CT/8b2d7n9uTiHvfoRDfqg7 qTHQDmIoSfVt08RuA3TL3AX7jAcNcr/Ps1ACUKzgrdX4emANu9ks+yi0H wNbytBEFCNNYyTJXaSAlnFia2f5Am/ujxwtWxNrwNzQ8qj5hM1p+l+iea YbZX62S2wscAfNmp8Mb6smUFcQ8kPQo9oGlUctQyFV1fshwaetdo6/oYM IFwMKHJVpd447w5d6MuOltlK+L98o20SnZ0V/YqJTiylQgzTUHPMO/qkb Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10677"; a="341334022" X-IronPort-AV: E=Sophos;i="5.98,338,1673942400"; d="scan'208";a="341334022" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Apr 2023 02:14:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10677"; a="719287056" X-IronPort-AV: E=Sophos;i="5.98,338,1673942400"; d="scan'208";a="719287056" Received: from orsmsx603.amr.corp.intel.com ([10.22.229.16]) by orsmga008.jf.intel.com with ESMTP; 12 Apr 2023 02:14:19 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Wed, 12 Apr 2023 02:14:18 -0700 Received: from orsmsx602.amr.corp.intel.com (10.22.229.15) by ORSMSX611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Wed, 12 Apr 2023 02:14:18 -0700 Received: from orsedg603.ED.cps.intel.com (10.7.248.4) by orsmsx602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23 via Frontend Transport; Wed, 12 Apr 2023 02:14:18 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.168) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.23; Wed, 12 Apr 2023 02:14:18 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MSSCIsF8nj6W+hZ6cd0vPAoFkc0NXWNmiuIuq1Uc1UkQKZW4wyIygb9+qjLu44t89qA/Gx+F+b5dZODQK2wYZT8bN5Zy+D5ugXFKbIp6J+g2t6EyO28hNpDYgC5bxja4z70FQd6mB6QAfaIydqQEdY2SMcHj3wyh2IWuy4ttkfkrhsaFoop/3xm0n983RaDJWMW/rwBh9R1/cPG107Ue90RcpeHbT0QEfCz7XUZz32cHKZJguYjhq/fH+iToO9OVvgSv62Pjc69sNv/mRbGM2NjfMCmfHp33KEbxEInWEhuVIT55ot/0kjKPNA+fRrBzXXcCDH2kTDZ8zpWdeWoO4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZCBfmX7VH4OWEyLOXzDSLuNt5/rJ6JN/8xJdJW2Ie1c=; b=DLq0ejtKI2iIRQqwW0mMvfEEWSNStVADY4Pf+OCoIekDOOfJfVaepaZJh3QOdVRYan4S9Vztz3NAmMddEIMI952x3O9UmrJJjyTBYHrhWuNm+QAzAUqFlm26lpzoBtLZ9KZpzx56RpvTay7SHc5nwfUALV9t+O+h1524ct0ug5IsNWcwe5vxE5vbq8BzvMdue1tOeHkO9AvQEQJJeStBkq63lgMwSYnr8Ya8lxSlZo73MVcVshHX7HOYUb3gNGlM+xVLtdcQ5N9Mkwsn7js+FzLhioaiSMdqQa/Ms/DFnc+dfOSqqWAG2LshTU+NJvSnovpITuP7OVofyN+h0ysghQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from PH0PR11MB5880.namprd11.prod.outlook.com (2603:10b6:510:143::14) by PH8PR11MB6681.namprd11.prod.outlook.com (2603:10b6:510:1c4::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.28; Wed, 12 Apr 2023 09:14:16 +0000 Received: from PH0PR11MB5880.namprd11.prod.outlook.com ([fe80::3265:f579:62a6:8a0]) by PH0PR11MB5880.namprd11.prod.outlook.com ([fe80::3265:f579:62a6:8a0%5]) with mapi id 15.20.6277.035; Wed, 12 Apr 2023 09:14:16 +0000 From: "Zhang, Qiang1" To: Uladzislau Rezki , "Paul E. McKenney" CC: "frederic@kernel.org" , "joel@joelfernandes.org" , "qiang.zhang1211@gmail.com" , "rcu@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH v3] rcu/kvfree: Prevents cache growing when the backoff_page_cache_fill is set Thread-Topic: [PATCH v3] rcu/kvfree: Prevents cache growing when the backoff_page_cache_fill is set Thread-Index: AQHZaiXby4kI/lAQlUSTC1cR7UMpS68lNdWAgABJBmCAAK/VgIAAAf6ggAAHJACAAB0hgIAAB8aAgADFFUA= Date: Wed, 12 Apr 2023 09:14:15 +0000 Message-ID: References: <2159c88e-ec99-4ad6-a166-baf4199d138f@paulmck-laptop> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH0PR11MB5880:EE_|PH8PR11MB6681:EE_ x-ms-office365-filtering-correlation-id: 795bf110-3ce7-41eb-48e9-08db3b3649fe x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: R67tgjyp4hJ0SqFf6KyDAPU4ubAfQPxxXkSAEHz6kMEdsN1vCwO2KGqJ5jH/2D2LFiWTvRN/jdKGNcT4qvi13y7bnvHqimYuZ3eeIxKK0fBp5UzhNqknDgdht/AGIKR35WKPKb3c4ZeASCq9tHXt+Ru/zlJma8ahI1GyZ2X3u+E3PQKBO1FEJmzAEKz1AG83OQjCfwdm1/r/pT8RSAGqo2594VxTutI82CJrrWZvPYDii/tnvQb1YgNYTjxrDOpmKWiv036FoVmqMoxxNWHUKdS4eMGzm6/O0c8xsNdvPj8ryBkjBJrH7sCZFJYjBlkfIDsLFKlDd+kpFzkSqfHEzBCJEkw0wZGOZx0TPCmehC+LoBsD8jvNtw2Cj4JqRqwEfnSPYQDp6Qo38EdF/L2fdHTgOeetjPI5rSlIM58AC8axjB9Z1cbYgq98iNwfooHqboaCXbb5BITu/nn01PFxHLk0ivI/FPBNkFSFiNoKseg5nKcTvPJpXZ8HsmHmiG9KTLblDfNZCbxraXLnWDGK/Em5uJ1RTsUT4EJOwolaBUFcx7nnPwRGR0FdCLDWwrmvk2TozCWJhmBSnzbys5QLyDKAsM4fGMqIyI04PnYE79IxTHTZNf8ClvfuTwvnLoYQ x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR11MB5880.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(396003)(346002)(39860400002)(136003)(366004)(376002)(451199021)(76116006)(83380400001)(71200400001)(7696005)(54906003)(110136005)(6506007)(26005)(186003)(9686003)(82960400001)(33656002)(2906002)(52536014)(38100700002)(5660300002)(122000001)(4326008)(66446008)(66946007)(41300700001)(66476007)(64756008)(8936002)(38070700005)(316002)(8676002)(66556008)(86362001)(55016003)(478600001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?L01nL2dPUFFwL1E5eWQ2S1RGS09rN2tCUHlYRTFDWjJlWnN0MnEwZitHaXgr?= =?utf-8?B?ODg5alB5bGd0K1ZCM1ZLRDVUQTVQWXpUV3JMenQrdEh6T2VvclVVRTR2cW5J?= =?utf-8?B?bXZrbFZoSDFIdkN1MTBOWGJJMzJpVmRIMURGZTkvQlNZc0p6UlRnWFZ1bEda?= =?utf-8?B?RkhjdDdGckxidEtLUVNNakZKVGxGUGxsWVF5ZTlHcnROcU1MU0h0Z2UwZVhP?= =?utf-8?B?RHpUbnFmaFNNTk9tQSswT3o3bnFoQXlnYnBycEFIUldTdzhEejllVTcvaExG?= =?utf-8?B?Y2gzTEdBcFRPMWY1dVJhV3Zib2hLSk1ia0tWdjBneEdnSEx4VDRod2N6S2Mr?= =?utf-8?B?M1lLbXNZV0FsY0x6YzZQN0tkUXgvUmpudjY5WThVQjhFVm1NNURDcFhwQzdM?= =?utf-8?B?Q0x0L3dOKy9aeHk3a0pEZmo5eUFmNFZxZ29HUW44UUhrV3pKSFBIbnZxelQ4?= =?utf-8?B?eklSRUdIdW5EcEdLZC9HeHRUQmh6WGRuSTFWWlJwUDhZOERhWlNBSFNGNExm?= =?utf-8?B?dGk0cTdsbDdOcDRMWHUveUh1TVVldDcxVmNPcXo0cHNobFRzMmpuaGlWd1RE?= =?utf-8?B?UlVhbEJTOFdRa0Mvd3E1bTIydVp1NUcrcjMwNE1NU3QydVIvR3d1am4xTXJw?= =?utf-8?B?SHFSRGYzTW5BNUdheGkxbStiQ3k4V1J2MlBHdUhIcWlSaEJacFdPdXZKRElV?= =?utf-8?B?WWxBaGdpcTNsR1NCeEphUmJLZ25nMlA3SWRHSDlOUmN2ZmJTLzBHRnhNWG1J?= =?utf-8?B?NW1uY0FOWS9wVzVmOHBYL2NxaVArblM1TW1CTUMrb2E5ZEx0dE1Gc3ZUSnJN?= =?utf-8?B?UmNxT1BUZ1pKYjY5cEpjWVFTSERtQjBIMi9nZ0hkK0N4bDJ1ajI0bEZWejJT?= =?utf-8?B?TDBKcCtKcmI4ZUtlbnhram9hWElxTDAwWWovbUVXQUdiQzN3ZHNycEV5dGY2?= =?utf-8?B?MGtVdSs2S1F5OG9GQmJhRnJ5OTdBV0l2YTVERTNkSHBjNzcrNjBYZDB6dGZh?= =?utf-8?B?L0pxR0tseE51QnI0TWxsSGZ5aEM1MERtOTJFRUVhNlpkRTVuOHcyN0JCMjhI?= =?utf-8?B?UkVwRVFVUDZ4bFkzSkEvclhoazJKTzg2dzZYc3AreGZZWDBGcU5UTFB3Q3c1?= =?utf-8?B?bWp3ek1tbU9CZjlzKzI3eDFNMFQxL0QvQ1pXZGdyNjJKZG55NGVTaWFmMlM1?= =?utf-8?B?dFZQZmdhaktUNlZKdFRCNjcxZHBzdXNwekRFTFNremRybk5CM0pCSDk4SUIr?= =?utf-8?B?QlFHSUpkcFdFYXBUR0pBMTNMeFJoRnNDczMzL1NabGc5SFM1SEcrdFprNG9K?= =?utf-8?B?NW9vZC9PRXpiY1NTcFFxM1pOejNZeEx0aUlrRlZHalJueWtmNXpFNjV4enZE?= =?utf-8?B?TDB2Nm9SK05nZGtVMnRqR0VwTmg0cFRxTlcwK3RhazdPVjVuWGtBZkhDT3Jk?= =?utf-8?B?VzVSRWVoc1Nlc3YybG1yMU5xdHNRelEwYzJBVE40TXg4ZlVETVJPTDNRaXRR?= =?utf-8?B?WmtpOGZMcUp3R21nd3UrTDlNaHQrc3hnMTBROVlNMkVaVkRvZXM4bnk2Y1dm?= =?utf-8?B?bXpVVlVBYVFqVXkrR0o4UWN1R3JvTVlGN3RaVjdlMUoyTnc4UzlzTUJtTW1i?= =?utf-8?B?NVJwcnFpV3MwYk1oNW51L2xGaVdSRlptbmdrYUR6VHB1NTFic1A2N3I1U1ZS?= =?utf-8?B?M3hrSi8yMjg4bW9MMGF4QTNoWGVicE8rOGZ2K3JPV1VPYUF0MFNlVjNWSUxU?= =?utf-8?B?TnBDOUkwUEhIWWtqV3FOWXV4RkNDbmk3S2NYM0t0d0VPN2VnaE8zcUxWRHFE?= =?utf-8?B?SDFVLytsMzIyeU1tbVdqTHdXVW1OTjNvSTZxMnViTkNJQ2taUjErZjlPM0Zi?= =?utf-8?B?RTY3cUtZbTBXVUsxNWhGZ2VrMm91WDM3K1B0bXhSQ2pvTkJtckg0MVUzaDVK?= =?utf-8?B?NjUrMnNLNWoyYXRhZ0NSYTkweWVwSG1vZ2VOcUpJOURLclNtODNBV3lJREhQ?= =?utf-8?B?NElHZUNZMFdSLytDTDFRaHpHWTJPWk5EZTM3VFJHSUdWNlZuOW02eEQxVnRY?= =?utf-8?B?L0VVc1FSMURqT0JQbjdGYmluSTNjM3ljL0dQR0RaVXlTRDZ2MzV5N3lBdCtp?= =?utf-8?Q?W0ODIEs4f0L5YUx6kjYYTVWlN?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5880.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 795bf110-3ce7-41eb-48e9-08db3b3649fe X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2023 09:14:15.8397 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /vCq3mYFTI9DoLkdRTIL0RoIvx1p9Vols77bhJkpqP9yeqSyNa+MSymbYVvviBlvkibbzfe6YuoRK6d9N3TVxg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR11MB6681 X-OriginatorOrg: intel.com Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Tue, Apr 11, 2023 at 04:58:22PM +0200, Uladzislau Rezki wrote: > > On Tue, Apr 11, 2023 at 02:42:27PM +0000, Zhang, Qiang1 wrote: > > > > > Currently, in kfree_rcu_shrink_scan(), the drain_page_cache()=20 > > > > > is executed before kfree_rcu_monitor() to drain page cache, if=20 > > > > > the bnode structure's->gp_snap has done, the kvfree_rcu_bulk()=20 > > > > > will fill the page cache again in kfree_rcu_monitor(), this=20 > > > > > commit add a check for krcp=20 > > > > > structure's->backoff_page_cache_fill in put_cached_bnode(), if=20 > > > > > the krcp structure's->backoff_page_cache_fill is set, prevent pag= e cache growing and disable allocated page in fill_page_cache_func(). > > > > >=20 > > > > > Signed-off-by: Zqiang > > > > > > > > > >Much improved! But still some questions below... > > > > > > > > > > Thanx, Paul > > > > > > > > > > --- > > > > > kernel/rcu/tree.c | 4 +++- > > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > >=20 > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index=20 > > > > > cc34d13be181..9d9d3772cc45 100644 > > > > > --- a/kernel/rcu/tree.c > > > > > +++ b/kernel/rcu/tree.c > > > > > @@ -2908,6 +2908,8 @@ static inline bool =20 > > > > > put_cached_bnode(struct kfree_rcu_cpu *krcp, > > > > > struct kvfree_rcu_bulk_data *bnode) { > > > > > + if (atomic_read(&krcp->backoff_page_cache_fill)) > > > > > + return false; > > > > > > > > > >This will mean that under low-memory conditions, we will keep=20 > > > > >zero pages in ->bkvcache. All attempts to put something there wil= l fail. > > > > > > > > > >This is probably not an issue for structures containing an=20 > > > > >rcu_head that are passed to kfree_rcu(p, field), but doesn't=20 > > > > >this mean that > > > > >kfree_rcu_mightsleep() unconditionally invokes synchronize_rcu()? > > > > >This could seriously slow up freeing under low-memory=20 > > > > >conditions, which might exacerbate the low-memory conditions. > > > >=20 > > > > Thanks for mentioning this, I didn't think of this before=F0=9F=98= =8A. > > > >=20 > > > > > > > > > >Is this really what we want? Zero cached rather than just fewer c= ached? > > > > > > > > > > > > > > > > > > > > // Check the limit. > > > > > if (krcp->nr_bkv_objs >=3D rcu_min_cached_objs) > > > > > return false; > > > > > @@ -3221,7 +3223,7 @@ static void fill_page_cache_func(struct wor= k_struct *work) > > > > > int i; > > > > > =20 > > > > > nr_pages =3D atomic_read(&krcp->backoff_page_cache_fill) ? > > > > > - 1 : rcu_min_cached_objs; > > > > > + 0 : rcu_min_cached_objs; > > > > > =20 > > > > > for (i =3D 0; i < nr_pages; i++) { > > > > > > > > > >I am still confused as to why we start "i" at zero rather than=20 > > > > >at > > > > >->nr_bkv_objs. What am I missing here? > > > >=20 > > > >=20 > > > > No, you are right, I missed this place.=20 > > > >=20 > > > > --- a/kernel/rcu/tree.c > > > > +++ b/kernel/rcu/tree.c > > > > @@ -2908,6 +2908,8 @@ static inline bool =20 > > > > put_cached_bnode(struct kfree_rcu_cpu *krcp, > > > > struct kvfree_rcu_bulk_data *bnode) { > > > > + if (atomic_read(&krcp->backoff_page_cache_fill)) > > > > + return false; > > > > > > > >This is broken, unfortunately. If a low memory condition we fill=20 > > > >fill a cache with at least one page anyway because of we do not=20 > > > >want to hit a slow path. > > >=20 > > > Thanks remind, please ignore my v4 patch, how about the following? > > >=20 > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index=20 > > > 41daae3239b5..e2e8412e687f 100644 > > > --- a/kernel/rcu/tree.c > > > +++ b/kernel/rcu/tree.c > > > @@ -3238,6 +3238,9 @@ static void fill_page_cache_func(struct work_st= ruct *work) > > > free_page((unsigned long) bnode); > > > break; > > > } > > > + > > > + if (atomic_read(&krcp->backoff_page_cache_fill)) > > > + break; > > > } > > It does not fix an "issue" you are reporting. kvfree_rcu_bulk()=20 > > function can still fill it back. IMHO, the solution here is to=20 > > disable cache if a low memory condition and enable back later on. > >=20 > > The cache size is controlled by the rcu_min_cached_objs variable. We=20 > > can set it to 1 and restore it back to original value to make the=20 > > cache operating as before. >=20 > It would be best to use a second variable for this. Users might get=20 > annoyed if their changes to rcu_min_cached_objs got overwritten once=20 > things got set back to normal operation. >=20 >Agree. So we do not make it visible over sysfs interface for user that we = manipulate it. > > The rcu_min_cached_objs is read-only, Users cannot be set rcu_min_cached_ob= js dynamically.=20 -r--r--r-- 1 root root 4.0K Apr 12 01:08 rcu_min_cached_objs diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 41daae3239b5..0e9f83562823 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -2909,7 +2909,8 @@ put_cached_bnode(struct kfree_rcu_cpu *krcp, struct kvfree_rcu_bulk_data *bnode) { // Check the limit. - if (krcp->nr_bkv_objs >=3D rcu_min_cached_objs) + if ((atomic_read(&krcp->backoff_page_cache_fill) && krcp->nr_bkv_ob= js) || + krcp->nr_bkv_objs >=3D rcu_min_cached_objs) return false; llist_add((struct llist_node *) bnode, &krcp->bkvcache); thoughts? Thanks Zqiang > >-- >Uladzislau Rezki