From: Yajun Deng <yajun.deng@linux.dev>
To: Eric Dumazet <edumazet@google.com>
Cc: rostedt@goodmis.org, mhiramat@kernel.org, dennis@kernel.org,
tj@kernel.org, cl@linux.com, mark.rutland@arm.com,
davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Alexander Lobakin <aleksander.lobakin@intel.com>,
linux-trace-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH net-next v7] net/core: Introduce netdev_core_stats_inc()
Date: Mon, 9 Oct 2023 18:58:27 +0800 [thread overview]
Message-ID: <078f662d-a73f-766b-3a07-c82cd37026c5@linux.dev> (raw)
In-Reply-To: <CANn89iJHtYJjp6zPc2PVLAWuN88BQc5OntjrAf7f6QOcqP+B=g@mail.gmail.com>
On 2023/10/9 18:16, Eric Dumazet wrote:
> On Mon, Oct 9, 2023 at 11:43 AM Yajun Deng <yajun.deng@linux.dev> wrote:
>>
>> On 2023/10/9 17:30, Eric Dumazet wrote:
>>> On Mon, Oct 9, 2023 at 10:36 AM Yajun Deng <yajun.deng@linux.dev> wrote:
>>>> On 2023/10/9 16:20, Eric Dumazet wrote:
>>>>> On Mon, Oct 9, 2023 at 10:14 AM Yajun Deng <yajun.deng@linux.dev> wrote:
>>>>>> On 2023/10/9 15:53, Eric Dumazet wrote:
>>>>>>> On Mon, Oct 9, 2023 at 5:07 AM Yajun Deng <yajun.deng@linux.dev> wrote:
>>>>>>>
>>>>>>>> 'this_cpu_read + this_cpu_write' and 'pr_info + this_cpu_inc' will make
>>>>>>>> the trace work well.
>>>>>>>>
>>>>>>>> They all have 'pop' instructions in them. This may be the key to making
>>>>>>>> the trace work well.
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I need your help on percpu and ftrace.
>>>>>>>>
>>>>>>> I do not think you made sure netdev_core_stats_inc() was never inlined.
>>>>>>>
>>>>>>> Adding more code in it is simply changing how the compiler decides to
>>>>>>> inline or not.
>>>>>> Yes, you are right. It needs to add the 'noinline' prefix. The
>>>>>> disassembly code will have 'pop'
>>>>>>
>>>>>> instruction.
>>>>>>
>>>>> The function was fine, you do not need anything like push or pop.
>>>>>
>>>>> The only needed stuff was the call __fentry__.
>>>>>
>>>>> The fact that the function was inlined for some invocations was the
>>>>> issue, because the trace point
>>>>> is only planted in the out of line function.
>>>> But somehow the following code isn't inline? They didn't need to add the
>>>> 'noinline' prefix.
>>>>
>>>> + field = (unsigned long *)((void *)this_cpu_ptr(p) + offset);
>>>> + WRITE_ONCE(*field, READ_ONCE(*field) + 1);
>>>>
>>>> Or
>>>> + (*(unsigned long *)((void *)this_cpu_ptr(p) + offset))++;
>>>>
>>> I think you are very confused.
>>>
>>> You only want to trace netdev_core_stats_inc() entry point, not
>>> arbitrary pieces of it.
>>
>> Yes, I will trace netdev_core_stats_inc() entry point. I mean to replace
>>
>> + field = (__force unsigned long
>> __percpu *)((__force void *)p + offset);
>> + this_cpu_inc(*field);
>>
>> with
>>
>> + field = (unsigned long *)((void *)this_cpu_ptr(p) + offset);
>> + WRITE_ONCE(*field, READ_ONCE(*field) + 1);
>>
>> Or
>> + (*(unsigned long *)((void *)this_cpu_ptr(p) + offset))++;
>>
>> The netdev_core_stats_inc() entry point will work fine even if it doesn't
>> have 'noinline' prefix.
>>
>> I don't know why this code needs to add 'noinline' prefix.
>> + field = (__force unsigned long __percpu *)((__force void *)p + offset);
>> + this_cpu_inc(*field);
>>
> C compiler decides to inline or not, depending on various factors.
>
> The most efficient (and small) code is generated by this_cpu_inc()
> version, allowing the compiler to inline it.
>
> If you copy/paste this_cpu_inc() twenty times, then the compiler
> would not inline the function anymore.
Got it. Thank you.
next prev parent reply other threads:[~2023-10-09 10:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-07 5:06 [PATCH net-next v7] net/core: Introduce netdev_core_stats_inc() Yajun Deng
2023-10-07 5:29 ` Eric Dumazet
2023-10-07 6:34 ` Yajun Deng
2023-10-08 6:45 ` Eric Dumazet
2023-10-08 6:59 ` Yajun Deng
2023-10-08 7:18 ` Eric Dumazet
2023-10-08 8:44 ` Yajun Deng
2023-10-08 8:53 ` Eric Dumazet
2023-10-08 9:12 ` Yajun Deng
2023-10-09 3:07 ` Yajun Deng
2023-10-09 7:53 ` Eric Dumazet
2023-10-09 8:13 ` Yajun Deng
2023-10-09 8:20 ` Eric Dumazet
2023-10-09 8:36 ` Yajun Deng
2023-10-09 9:30 ` Eric Dumazet
2023-10-09 9:43 ` Yajun Deng
2023-10-09 10:16 ` Eric Dumazet
2023-10-09 10:58 ` Yajun Deng [this message]
2023-10-09 14:28 ` Steven Rostedt
2023-10-10 3:46 ` Yajun Deng
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=078f662d-a73f-766b-3a07-c82cd37026c5@linux.dev \
--to=yajun.deng@linux.dev \
--cc=aleksander.lobakin@intel.com \
--cc=cl@linux.com \
--cc=davem@davemloft.net \
--cc=dennis@kernel.org \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mhiramat@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tj@kernel.org \
/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.