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 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.