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 48FC2C04AA5 for ; Thu, 25 Aug 2022 00:49:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D8B86940007; Wed, 24 Aug 2022 20:49:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D3ADC6B0078; Wed, 24 Aug 2022 20:49:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BDB94940007; Wed, 24 Aug 2022 20:49:44 -0400 (EDT) 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 AE0996B0075 for ; Wed, 24 Aug 2022 20:49:44 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 8BD73140435 for ; Thu, 25 Aug 2022 00:49:44 +0000 (UTC) X-FDA: 79836282288.18.1881358 Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) by imf28.hostedemail.com (Postfix) with ESMTP id 4BFC2C006A for ; Thu, 25 Aug 2022 00:49:44 +0000 (UTC) Received: by mail-io1-f41.google.com with SMTP id 62so14793956iov.5 for ; Wed, 24 Aug 2022 17:49:43 -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=N5i57tWQ+irbW+vnVsv9droGyD3UZBCcowhtHNvVvPU=; b=s/ooz3pquL0Gz0cf/qsj/faJ+E6H3xbieImxrb1Xqr7y1hyNM/EvkqoGAOKnb9BFDe irGhnXyWcfg20C8oUBPV5LSCI3iiMrezDMfq0eAm2Q+ISsR0r5IC2UH7dGY6jzZZe0DC mQyo+32zxbNZJ0cLIPk66CV9E3rQf2ITAzQ2A= 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=N5i57tWQ+irbW+vnVsv9droGyD3UZBCcowhtHNvVvPU=; b=coVm+4I8hcxnubix5lckeWuDw2Px0vTq6hnfy3ItB6eK9CQCMrfSkj9ty+2M20ByNv v3Z3ll1vXTuiGf9CgRXosYGCflrgIr662QRnumQ1o5odr88lKBtCOAbbAe8u8+xKL8Rb +bv274fSVPgPZo5nXWVqWwnDuUSE3x+PCeBmUWgGH9MwdYTXjGq4kwke+lakzLcQMKkt nL5vDEuDR2yjazudV+JJ+TaJDl8+SeyGaqR6McMBcYPjl0IGPZtMbExOuw65FIyPpygc BHpSW4wjGg1xKiqJiOx1pu+99hRzMA1EoNxtS7nf2to5dhz62BuJXrDj5OmuqztxZOGk Asbw== X-Gm-Message-State: ACgBeo2JoaYyI4FvuRFeYPPkisSxAl7VwEzxl7Z4MOTm/PeH90jE5nYf vOZayR6S8iGcPH4ICxZMqWF2G4ocn+foOmzJcJTv2A== X-Google-Smtp-Source: AA6agR6468ijP2gfHY/mTIsuu4vjhOIIKZZRxIDj36hgNKBAeicdpHwPHQjKgrWvxkmVcfnoCSnS9CEdCfOyHcuJXG8= X-Received: by 2002:a05:6638:40a8:b0:346:8e3c:8141 with SMTP id m40-20020a05663840a800b003468e3c8141mr668278jam.107.1661388583517; Wed, 24 Aug 2022 17:49:43 -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:49:31 -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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661388584; 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=N5i57tWQ+irbW+vnVsv9droGyD3UZBCcowhtHNvVvPU=; b=hY05/2/lqGG8PEJ8LenjVBEAmYSdrgIH6X192zXivgLh/hXMy0AqmjRUteyg6Oa2JQZchb bX1MQ2VnmdYmN9zQuGDUhGTqN0AmnP6Uu3Cush5iBbpKkGnDRVYIf0UAW84rGOK6VHSiI9 19fz4WSdJ4bJcmBwrMTjQad4MGGAzMg= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b="s/ooz3pq"; spf=pass (imf28.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.166.41 as permitted sender) smtp.mailfrom=joel@joelfernandes.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661388584; a=rsa-sha256; cv=none; b=QctWd0Z+peFzxBMGIzN/fw++k6J8ZmyNzpxtqAxElxDGCnJhK4Mtg6QizpAsnrY7cPXwsF baiu0MkrP5iOvh+ZwHK2ZKMFaMuouqqxQygikWMsy3BATEwTVhXNKEXtCRGJr3OkOxGGRC lBv/c8OkmG2UIf6vJldrvFhFiZAJcrI= X-Rspamd-Queue-Id: 4BFC2C006A Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b="s/ooz3pq"; spf=pass (imf28.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.166.41 as permitted sender) smtp.mailfrom=joel@joelfernandes.org; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: rjy5mfknafrut7x7q7dwo5kdu8wknynk X-HE-Tag: 1661388584-937582 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:35 PM Joel Fernandes wrote: > > 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). Just as FYI, I see rcu_barrier() used in Alexei's patch - that will flush the lazy CBs to keep rcu_barrier() both correct and performant. At that point call_rcu_lazy() is equivalent to call_rcu() as we no longer kept the callbacks a secret from the rest of the system. Thanks, - Joel