From: Kuan-Wei Chiu <visitorckw@gmail.com>
To: Eric Dumazet <edumazet@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
netdev@vger.kernel.org, Neal Cardwell <ncardwell@google.com>,
Kuniyuki Iwashima <kuniyu@google.com>,
Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [PATCH 0/2] rbree: inline rb_first() and rb_last()
Date: Mon, 17 Nov 2025 19:35:15 +0800 [thread overview]
Message-ID: <aRsIc-7VImwUb58q@google.com> (raw)
In-Reply-To: <CANn89iKYLf1AWi_YvK47NvQXb0B31NHxF736dXYg=2E5Xxg0Ew@mail.gmail.com>
On Sun, Nov 16, 2025 at 10:41:31AM -0800, Eric Dumazet wrote:
> On Sun, Nov 16, 2025 at 10:00 AM Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> >
> > Hi Eric,
> >
> > On Fri, Nov 14, 2025 at 02:06:44PM +0000, Eric Dumazet wrote:
> > > Inline these two small helpers, heavily used in TCP and FQ packet scheduler,
> > > and in many other places.
> > >
> > > This reduces kernel text size, and brings an 1.5 % improvement on network
> > > TCP stress test.
> >
> > Thanks for the patch!
> >
> > Just out of curiosity, do you think rb_first() and rb_last() would be
> > worth marking with __always_inline?
>
> I have not seen any difference, what compilers are you using that
> would not inline this ?
I haven't specifically measured the difference. I was curious if using
__always_inline would be better to guarantee the compiler inlines the
function, given that the inline keyword is only a suggestion, and this
optimization is important for performance in a hot path.
Also, FWIW, I tried building an arm64 defconfig with LLVM both with and
without __always_inline. I got the same results from size vmlinux, but
scripts/bloat-o-meter output is as follows:
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-8 (-8)
Function old new delta
__aarch32_sigret_code_end 24 16 -8
Total: Before=129127208516005098430, After=129127208516005098422, chg -0.00%
Regards,
Kuan-Wei
prev parent reply other threads:[~2025-11-17 11:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-14 14:06 [PATCH 0/2] rbree: inline rb_first() and rb_last() Eric Dumazet
2025-11-14 14:06 ` [PATCH 1/2] rbtree: inline rb_first() Eric Dumazet
2025-11-14 14:06 ` [PATCH 2/2] rbtree: inline rb_last() Eric Dumazet
2025-11-16 18:00 ` [PATCH 0/2] rbree: inline rb_first() and rb_last() Kuan-Wei Chiu
2025-11-16 18:41 ` Eric Dumazet
2025-11-17 11:35 ` Kuan-Wei Chiu [this message]
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=aRsIc-7VImwUb58q@google.com \
--to=visitorckw@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).