From: Kunwu Chan <kunwu.chan@linux.dev>
To: Alice Ryhl <aliceryhl@google.com>
Cc: ojeda@kernel.org, alex.gaynor@gmail.com, boqun.feng@gmail.com,
gary@garyguo.net, bjorn3_gh@protonmail.com,
benno.lossin@proton.me, a.hindborg@kernel.org, tmgross@umich.edu,
dakr@kernel.org, nathan@kernel.org,
nick.desaulniers+lkml@gmail.com, morbo@google.com,
justinstitt@google.com, rust-for-linux@vger.kernel.org,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
Kunwu Chan <kunwu.chan@hotmail.com>,
Grace Deng <Grace.Deng006@gmail.com>
Subject: Re: [PATCH] rust: page:: optimize rust symbol generation for Page
Date: Tue, 18 Mar 2025 10:30:39 +0800 [thread overview]
Message-ID: <0a5408e8-aefc-4e2d-8329-094e17484890@linux.dev> (raw)
In-Reply-To: <Z9f6Zi2_eZFFY0Q7@google.com>
On 2025/3/17 18:33, Alice Ryhl wrote:
> On Mon, Mar 17, 2025 at 05:40:04PM +0800, Kunwu Chan wrote:
>> From: Kunwu Chan <kunwu.chan@hotmail.com>
>>
>> When build the kernel using the llvm-18.1.3-rust-1.85.0-x86_64
>> with ARCH=arm64, the following symbols are generated:
>>
>> $nm vmlinux | grep ' _R'.*Page | rustfilt
>> ffff8000805b6f98 T <kernel::page::Page>::alloc_page
>> ffff8000805b715c T <kernel::page::Page>::fill_zero_raw
>> ffff8000805b720c T <kernel::page::Page>::copy_from_user_slice_raw
>> ffff8000805b6fb4 T <kernel::page::Page>::read_raw
>> ffff8000805b7088 T <kernel::page::Page>::write_raw
>> ffff8000805b72fc T <kernel::page::Page as core::ops::drop::Drop>::drop
>>
>> These Rust symbols are trivial wrappers around the C functions
>> alloc_pages, kunmap_local and __free_pages.
>> It doesn't make sense to go through a trivial wrapper for these
>> functions, so mark them inline.
>>
>> Link: https://github.com/Rust-for-Linux/linux/issues/1145
>> Suggested-by: Alice Ryhl <aliceryhl@google.com>
>> Co-developed-by: Grace Deng <Grace.Deng006@Gmail.com>
>> Signed-off-by: Grace Deng <Grace.Deng006@Gmail.com>
>> Signed-off-by: Kunwu Chan <kunwu.chan@hotmail.com>
> For sure `alloc_page` and `drop` should be inline, but the other methods
> are not as simple. It is less clear that they should be inline.
>
> At the very least, the claim that they are a trivial wrapper around
> "kunmap_local" is false. They don't just call that method.
Yes, I'm not sure if that's the case, cause there are more layers of
nesting and it's more complex.
From objdump, it can be seen that LLVM will currently inline according
to the 'inline' mark.
$aarch64-linux-gnu-objdump -d vmlinux | rustfilt | grep -A 20
"kernel::page::"
ffff8000805b6f6c <kernel::page::page_align>:
ffff8000805b6f6c: d503245f bti c
ffff8000805b6f70: b13ffc08 adds x8, x0, #0xfff
ffff8000805b6f74: 54000062 b.cs ffff8000805b6f80
<kernel::page::page_align+0x14> // b.hs,
b.nlast
ffff8000805b6f78: 9274cd00 and x0, x8, #0xfffffffffffff000
ffff8000805b6f7c: d65f03c0 ret
ffff8000805b6f80: d503233f paciasp
ffff8000805b6f84: a9bf7bfd stp x29, x30, [sp, #-16]!
ffff8000805b6f88: 910003fd mov x29, sp
ffff8000805b6f8c: d0006420 adrp x0, ffff80008123c000
<core::unicode::unicode_data::white_sp
ace::WHITESPACE_MAP+0x6756>
ffff8000805b6f90: 910b6000 add x0, x0, #0x2d8
ffff8000805b6f94: 97e98ac3 bl ffff800080019aa0
<core::panicking::panic_const::panic_const
_add_overflow>
ffff8000805b6f98 <<kernel::pci::Device>::as_raw>:
ffff8000805b6f98: d503245f bti c
ffff8000805b6f9c: f9400008 ldr x8, [x0]
ffff8000805b6fa0: f1031d1f cmp x8, #0xc7
ffff8000805b6fa4: 54000069 b.ls ffff8000805b6fb0
<<kernel::pci::Device>::as_raw+0x18> // b
.plast
ffff8000805b6fa8: d1032100 sub x0, x8, #0xc8
ffff8000805b6fac: d65f03c0 ret
ffff8000805b6fb0: d503233f paciasp
ffff8000805b6fb4: a9bf7bfd stp x29, x30, [sp, #-16]!
ffff8000805b6fb8: 910003fd mov x29, sp
ffff8000805b6fbc: b0006420 adrp x0, ffff80008123b000
<core::unicode::unicode_data::white_sp
ace::WHITESPACE_MAP+0x5756>
Either we commits and merges the 'alloc_page' and 'drop' first.
I'll change it in the v2 version.
>
> Alice
--
Thanks,
Kunwu.Chan
prev parent reply other threads:[~2025-03-18 2:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-17 9:40 [PATCH] rust: page:: optimize rust symbol generation for Page Kunwu Chan
2025-03-17 10:33 ` Alice Ryhl
2025-03-18 2:30 ` Kunwu Chan [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=0a5408e8-aefc-4e2d-8329-094e17484890@linux.dev \
--to=kunwu.chan@linux.dev \
--cc=Grace.Deng006@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=justinstitt@google.com \
--cc=kunwu.chan@hotmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/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).