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: Re: [PATCH v2] bpf: Simplify code by using for_each_cpu_wrap()
Date: Thu, 08 Sep 2022 11:45:37 +0100 [thread overview]
Message-ID: <877d2ecffy.fsf_-_@stealth> (raw)
In-Reply-To: <CAPhsuW6+D0bfoPZdQ0j-NtCvgMED4YF-LyqXTQQHo+x7tw3yug@mail.gmail.com> (Song Liu's message of "Wed, 7 Sep 2022 17:55:23 -0700")
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.
As suggested, it's possible to use cpumask_next_wrap() like below -
diff --git a/kernel/bpf/percpu_freelist.c b/kernel/bpf/percpu_freelist.c
index 00b874c8e889..19e8eab70c40 100644
--- a/kernel/bpf/percpu_freelist.c
+++ b/kernel/bpf/percpu_freelist.c
@@ -68,9 +68,7 @@ static inline void ___pcpu_freelist_push_nmi(struct pcpu_freelist *s,
raw_spin_unlock(&head->lock);
return;
}
- cpu = cpumask_next(cpu, cpu_possible_mask);
- if (cpu >= nr_cpu_ids)
- cpu = 0;
+ cpu = cpumask_next_wrap(cpu, cpu_possible_mask, orig_cpu, false);
/* cannot lock any per cpu lock, try extralist */
if (cpu == orig_cpu &&
I can send an updated patch if this is preferred.
Thanks,
Punit
next prev parent reply other threads:[~2022-09-08 10:45 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 [this message]
2022-09-08 20:21 ` Song Liu
2022-09-09 8:59 ` [External] " Punit Agrawal
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=877d2ecffy.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.