From: Punit Agrawal <punit.agrawal@bytedance.com>
To: Song Liu <song@kernel.org>
Cc: Punit Agrawal <punit.agrawal@bytedance.com>,
Alexei Starovoitov <ast@kernel.org>, bpf <bpf@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
zhoufeng.zf@bytedance.com, Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>, Jiri Olsa <jolsa@kernel.org>
Subject: Re: [External] Re: Re: [PATCH v2] bpf: Simplify code by using for_each_cpu_wrap()
Date: Fri, 09 Sep 2022 09:59:07 +0100 [thread overview]
Message-ID: <87leqsc49w.fsf@stealth> (raw)
In-Reply-To: <CAPhsuW6fUuc6E7_EoY1h-cikDAT6AuLYCwb89JnaTeOcdrsNFw@mail.gmail.com> (Song Liu's message of "Thu, 8 Sep 2022 13:21:04 -0700")
Song Liu <song@kernel.org> writes:
> On Thu, Sep 8, 2022 at 3:45 AM Punit Agrawal
> <punit.agrawal@bytedance.com> wrote:
>>
>> Hi Song,
>>
>> Thanks for taking a look.
>>
>> Song Liu <song@kernel.org> writes:
>>
>> > On Wed, Sep 7, 2022 at 8:58 AM Punit Agrawal
>> > <punit.agrawal@bytedance.com> wrote:
>> >>
>> >> In the percpu freelist code, it is a common pattern to iterate over
>> >> the possible CPUs mask starting with the current CPU. The pattern is
>> >> implemented using a hand rolled while loop with the loop variable
>> >> increment being open-coded.
>> >>
>> >> Simplify the code by using for_each_cpu_wrap() helper to iterate over
>> >> the possible cpus starting with the current CPU. As a result, some of
>> >> the special-casing in the loop also gets simplified.
>> >>
>> >> No functional change intended.
>> >>
>> >> Signed-off-by: Punit Agrawal <punit.agrawal@bytedance.com>
>> >> ---
>> >> v1 -> v2:
>> >> * Fixed the incorrect transformation changing semantics of __pcpu_freelist_push_nmi()
>> >>
>> >> Previous version -
>> >> v1: https://lore.kernel.org/all/20220817130807.68279-1-punit.agrawal@bytedance.com/
>> >>
>> >> kernel/bpf/percpu_freelist.c | 48 ++++++++++++------------------------
>> >> 1 file changed, 16 insertions(+), 32 deletions(-)
>> >>
>> >> diff --git a/kernel/bpf/percpu_freelist.c b/kernel/bpf/percpu_freelist.c
>> >> index 00b874c8e889..b6e7f5c5b9ab 100644
>> >> --- a/kernel/bpf/percpu_freelist.c
>> >> +++ b/kernel/bpf/percpu_freelist.c
>> >> @@ -58,23 +58,21 @@ static inline void ___pcpu_freelist_push_nmi(struct pcpu_freelist *s,
>> >> {
>> >> int cpu, orig_cpu;
>> >>
>> >> - orig_cpu = cpu = raw_smp_processor_id();
>> >> + orig_cpu = raw_smp_processor_id();
>> >> while (1) {
>> >> - struct pcpu_freelist_head *head;
>> >> + for_each_cpu_wrap(cpu, cpu_possible_mask, orig_cpu) {
>> >> + struct pcpu_freelist_head *head;
>> >>
>> >> - head = per_cpu_ptr(s->freelist, cpu);
>> >> - if (raw_spin_trylock(&head->lock)) {
>> >> - pcpu_freelist_push_node(head, node);
>> >> - raw_spin_unlock(&head->lock);
>> >> - return;
>> >> + head = per_cpu_ptr(s->freelist, cpu);
>> >> + if (raw_spin_trylock(&head->lock)) {
>> >> + pcpu_freelist_push_node(head, node);
>> >> + raw_spin_unlock(&head->lock);
>> >> + return;
>> >> + }
>> >> }
>> >> - cpu = cpumask_next(cpu, cpu_possible_mask);
>> >> - if (cpu >= nr_cpu_ids)
>> >> - cpu = 0;
>> >
>> > I personally don't like nested loops here. Maybe we can keep
>> > the original while loop and use cpumask_next_wrap()?
>>
>> Out of curiosity, is there a reason to avoid nesting here? The nested
>> loop avoids the "cpu == orig_cpu" unnecessary check every iteration.
>
> for_each_cpu_wrap is a more complex loop, so we are using some
> checks either way.
That's true, indeed. While putting the patch together I wondering about
the need for a simpler / optimized version of for_each_cpu_wrap().
> OTOH, the nesting is not too deep (two loops then one if), so I guess
> current version is fine.
>
> Acked-by: Song Liu <song@kernel.org>
>
Thanks!
[...]
next prev parent reply other threads:[~2022-09-09 8:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-07 15:57 [PATCH v2] bpf: Simplify code by using for_each_cpu_wrap() Punit Agrawal
2022-09-08 0:55 ` Song Liu
2022-09-08 10:45 ` Punit Agrawal
2022-09-08 20:21 ` Song Liu
2022-09-09 8:59 ` Punit Agrawal [this message]
2022-09-10 23:30 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87leqsc49w.fsf@stealth \
--to=punit.agrawal@bytedance.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=song@kernel.org \
--cc=yhs@fb.com \
--cc=zhoufeng.zf@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.