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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 236A5C43334 for ; Thu, 2 Jun 2022 03:28:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233595AbiFBD2D (ORCPT ); Wed, 1 Jun 2022 23:28:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233576AbiFBD17 (ORCPT ); Wed, 1 Jun 2022 23:27:59 -0400 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 189EE5F8DA for ; Wed, 1 Jun 2022 20:27:58 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id j7so3757120pjn.4 for ; Wed, 01 Jun 2022 20:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:to:cc:references :from:in-reply-to:content-transfer-encoding; bh=sZ8GzRUQBIRnVHILPlLfnQyD91gR78EWniMrsU1AmRw=; b=nHuGvwI9o58j8lsqts87M+3kByKxsrc6rcVXPBo7v2yqnvCQuP72TbGLvtDo8h2mFj 8Xnpn2KWkwl1P+DnsYYpQTXW5BVC3B519Qv82bF5qq0UAX2M/jULgWfJbRC5MuMfMndm cOND4RdcH1iH4+nwv5uyffzq51YTrhYJmoffPJYJF07Sq9zts008GlGbpDVWuMv1eEZ7 wzuTBOfdo6T3yf4aOYR3Ux6hh7ntQKdi7w+mZbiHD2I885cviqJsPzeP/vO8A7JvXoPt hs19TKJ7omx4l47CplvvvddULcSUuUq4ZyUWL5ZNBjTRG92UMMPx+RC97qZ4Pne1KtDP mIVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :to:cc:references:from:in-reply-to:content-transfer-encoding; bh=sZ8GzRUQBIRnVHILPlLfnQyD91gR78EWniMrsU1AmRw=; b=A9mm/JE9BK8H9HLnllx/NW7RorjmfWw7kDbSumOOvNTo1tqY6gzecPo24fQU5NSbSU f9a2XM1xbKOcK39V7gSsCjleZM1C4YHNhj98dS4QkIhK7l8/inSNqt+adDrWYBpH5Woy knLcGz7q7dq3MooOqV2u1IZ8Fr/ra44NMeb8s0Mt2WPEzxaRr8B2IC9EbkZuffR/62ui quVaZBtCeO737Rl11CjCWFC808MlSyCum2GCvFqYXG/5xACXK58UPRLYyys2y9JEU3Wd UaxetA4MpH2clTUWvsyyUvykf5OPCtxRjP9jXMqAdW9GOK6jlWmz6z9pHPny6hogneO2 sQ+A== X-Gm-Message-State: AOAM5332qnS5aFVPmUPGcLotMEOmnkECOblOsTel8L4VZkijLiq9N1Fs hXBN3dxpds2z1QVlRT7rM+hzDw== X-Google-Smtp-Source: ABdhPJzbui9XgIru9OSL8mR+ctNjeib5PVobaIezJORsGKxZXTGoi8iyoBq7eJRaZvW/YntSXpqDVA== X-Received: by 2002:a17:902:a605:b0:163:8e47:8929 with SMTP id u5-20020a170902a60500b001638e478929mr2701820plq.69.1654140477634; Wed, 01 Jun 2022 20:27:57 -0700 (PDT) Received: from [10.71.57.194] ([139.177.225.241]) by smtp.gmail.com with ESMTPSA id p2-20020a170902c70200b001617541c94fsm2269689plp.60.2022.06.01.20.27.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jun 2022 20:27:57 -0700 (PDT) Message-ID: <6aedba89-51f4-c889-d3cc-5f513defb920@bytedance.com> Date: Thu, 2 Jun 2022 11:27:49 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: Re: [PATCH v4 1/2] bpf: avoid grabbing spin_locks of all cpus when no free elems To: Alexei Starovoitov Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Network Development , bpf , LKML , Xiongchun Duan , Muchun Song , Dongdong Wang , Cong Wang , Chengming Zhou References: <20220601084149.13097-1-zhoufeng.zf@bytedance.com> <20220601084149.13097-2-zhoufeng.zf@bytedance.com> <21ec90e3-2e89-09c1-fd22-de76e6794d68@bytedance.com> From: Feng Zhou In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2022/6/1 下午7:35, Alexei Starovoitov 写道: > On Wed, Jun 1, 2022 at 1:11 PM Feng Zhou wrote: >> 在 2022/6/1 下午5:50, Alexei Starovoitov 写道: >>> On Wed, Jun 1, 2022 at 10:42 AM Feng zhou wrote: >>>> static inline void ___pcpu_freelist_push(struct pcpu_freelist_head *head, >>>> @@ -130,14 +134,19 @@ static struct pcpu_freelist_node *___pcpu_freelist_pop(struct pcpu_freelist *s) >>>> orig_cpu = cpu = raw_smp_processor_id(); >>>> while (1) { >>>> head = per_cpu_ptr(s->freelist, cpu); >>>> + if (READ_ONCE(head->is_empty)) >>>> + goto next_cpu; >>>> raw_spin_lock(&head->lock); >>>> node = head->first; >>>> if (node) { >>> extra bool is unnecessary. >>> just READ_ONCE(head->first) >> As for why to add is_empty instead of directly judging head->first, my >> understanding is this, head->first is frequently modified during updating >> map, which will lead to invalid other cpus's cache, and is_empty is after >> freelist having no free elems will be changed, the performance will be >> better. > maybe. pls benchmark it. > imo wasting a bool for the corner case is not a good trade off. Yes, I will do and post the results as soon as possible, Thanks.