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 1C48DC04AA5 for ; Thu, 25 Aug 2022 00:35:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8CB60940007; Wed, 24 Aug 2022 20:35:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 87ABE6B0075; Wed, 24 Aug 2022 20:35:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7436E940007; Wed, 24 Aug 2022 20:35:57 -0400 (EDT) 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 63DD16B0074 for ; Wed, 24 Aug 2022 20:35:57 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 3C0B8A0D09 for ; Thu, 25 Aug 2022 00:35:57 +0000 (UTC) X-FDA: 79836247554.22.838D2C2 Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) by imf02.hostedemail.com (Postfix) with ESMTP id CD9A08004C for ; Thu, 25 Aug 2022 00:35:56 +0000 (UTC) Received: by mail-io1-f54.google.com with SMTP id c4so13945202iof.3 for ; Wed, 24 Aug 2022 17:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=9xIitNI2kBDldEzG9ZBQhex3Em4TszbN91MY6Jz1X20=; b=NipC4HT8qdJ6dNW3lQF7lZwdv/yzxPxGum9zcYOaa8h+RdPx23JEbaMdHN+pjWbLjS 1qBGrCs0fcipiASODRrxEKXpfML0IR1MysUBjvpJhBrlfBEEG77eQ+WI4B0FwtykOnNR 6QM9IDycVrAYkUayWE3+ijEPFPCzHOzCOUdyo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=9xIitNI2kBDldEzG9ZBQhex3Em4TszbN91MY6Jz1X20=; b=VxB3uj2Aq5ELvODbwNApQMEu5dwRrjCRHI6zpKfAer7w5B1HDLxikjOx+6TR3yRc0g oSnpdvrecsGaX4R3olh8K57SE+Ius1Jj1m60qkzuhv2O3ZSNclnIJe2MuJjEHtgwGLTA +6maCxU1sHYTb9f6Z2dhLmLhZjTy22oLeP0h/3V0q+CO2bqiKCPKAgUd8reWyoqj3fOR chMdkI1Zv+Vbtni/DbKBkxinBVSobwC4Mfv8Ey8oIOC2Jvho7fqqj5AL14TXvSEsdjC5 F33T11x2pQCV3ShZZNscU7ukHnpJTWafBkVmCXmvNP/wyLnuf/p9o2oYf5WqZFN31a4p EiSw== X-Gm-Message-State: ACgBeo0KPiD1MNs+LZplFZChAcFfytDfQYtrbMBjmjQUp3YxdMRqbD3n GWqLMnBZERSwJCrpHWp50nJkwHtODvMkKG0sXjgBuA== X-Google-Smtp-Source: AA6agR4ETsJ4XySAEUGPf5u5BXlXlFzx7xpAqcidLI/88KdMjz9oNbLzQqBEpBFN5rBXipXUzYi0QIunuq2eBqWvAQY= X-Received: by 2002:a05:6638:378c:b0:343:447e:e6e2 with SMTP id w12-20020a056638378c00b00343447ee6e2mr669419jal.118.1661387756170; Wed, 24 Aug 2022 17:35:56 -0700 (PDT) MIME-Version: 1.0 References: <20220819214232.18784-1-alexei.starovoitov@gmail.com> <20220819214232.18784-10-alexei.starovoitov@gmail.com> In-Reply-To: From: Joel Fernandes Date: Wed, 24 Aug 2022 20:35:44 -0400 Message-ID: Subject: Re: [PATCH v3 bpf-next 09/15] bpf: Batch call_rcu callbacks instead of SLAB_TYPESAFE_BY_RCU. To: Alexei Starovoitov Cc: Kumar Kartikeya Dwivedi , "David S. Miller" , Daniel Borkmann , Andrii Nakryiko , Tejun Heo , Delyan Kratunov , linux-mm , bpf , Kernel Team , Daniel Bristot de Oliveira Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661387756; a=rsa-sha256; cv=none; b=QN6Uby2c9RqGka71OPCgbJ+Ioj+zGavkhcsENlDB2QCPbHsK8/kg8UWeQpQVqPqcH5tJb7 3jhj71HF7khMzHMpCDpVBF17k9Mjcb7m1YCAxg9YSsgvrYq1BHB+Wf4DxRAxdVVgS18W/z wzfSTodpC+JF006r67D+4B+zpAbB6as= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b=NipC4HT8; dmarc=none; spf=pass (imf02.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.166.54 as permitted sender) smtp.mailfrom=joel@joelfernandes.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661387756; 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=9xIitNI2kBDldEzG9ZBQhex3Em4TszbN91MY6Jz1X20=; b=FnjXltjnijXzxhvU1lVN7RLVj4DrljYkUMqeWFmCxDWdlFGmBoGXDUGdAn0CyK0KBAJb90 JaHEgaRJsTsRGl/cLLioXT+kzYjErzwxwk1VS4tM+u7uM4a7nYaR24ziGFwY3VWvOSfjJg MdtEexIy+EMSTnqS628ytuBa6mDecyM= X-Rspamd-Queue-Id: CD9A08004C X-Rspam-User: Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b=NipC4HT8; dmarc=none; spf=pass (imf02.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.166.54 as permitted sender) smtp.mailfrom=joel@joelfernandes.org X-Stat-Signature: 9sr4wqh9p8huks83a41zxqp7jihq4jj7 X-Rspamd-Server: rspam05 X-HE-Tag: 1661387756-81274 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: On Wed, Aug 24, 2022 at 8:14 PM Alexei Starovoitov wrote: > > On Wed, Aug 24, 2022 at 12:59 PM Kumar Kartikeya Dwivedi > wrote: > > > > On Fri, 19 Aug 2022 at 23:43, Alexei Starovoitov > > wrote: > > > > > > From: Alexei Starovoitov > > > > > > SLAB_TYPESAFE_BY_RCU makes kmem_caches non mergeable and slows down > > > kmem_cache_destroy. All bpf_mem_cache are safe to share across different maps > > > and programs. Convert SLAB_TYPESAFE_BY_RCU to batched call_rcu. This change > > > solves the memory consumption issue, avoids kmem_cache_destroy latency and > > > keeps bpf hash map performance the same. > > > > > > Signed-off-by: Alexei Starovoitov > > > > Makes sense, there was a call_rcu_lazy work from Joel (CCed) on doing > > this batching using a timer + max batch count instead, I wonder if > > that fits our use case and could be useful in the future when it is > > merged? > > > > https://lore.kernel.org/rcu/20220713213237.1596225-2-joel@joelfernandes.org > > Thanks for the pointer. It looks orthogonal. > timer based call_rcu is for power savings. > I'm not sure how it would help here. Probably wouldn't hurt. > But explicit waiting_for_gp list is necessary here, > because two later patches (sleepable support and per-cpu rcu-safe > freeing) are relying on this patch. Hello Kumar and Alexei, Kumar thanks for the CC. I am seeing this BPF work for the first time so have not gone over it too much - but in case the waiting is synchronous by any chance, call_rcu_lazy() could hurt. The idea is to only queue callbacks that are not all that important to the system while keeping it quiet (power being the primary reason but Daniel Bristot would concur it brings down OS noise and helps RT as well). Have a good evening, Thank you, - Joel