rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Alice Ryhl <aliceryhl@google.com>
Cc: "Steven Rostedt" <rostedt@goodmis.org>,
	"Masami Hiramatsu" <mhiramat@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Josh Poimboeuf" <jpoimboe@kernel.org>,
	"Jason Baron" <jbaron@akamai.com>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Wedson Almeida Filho" <wedsonaf@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Andreas Hindborg" <a.hindborg@samsung.com>,
	linux-trace-kernel@vger.kernel.org,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] rust: add tracepoint support
Date: Thu, 6 Jun 2024 12:21:00 -0400	[thread overview]
Message-ID: <b36d92c8-6ce8-494f-951c-a6c24928f78d@efficios.com> (raw)
In-Reply-To: <CAH5fLghG8VpUnHbigO28k9nE9ZFS3EHGT2SE-0mZG1NtHF0qKg@mail.gmail.com>

On 2024-06-06 12:16, Alice Ryhl wrote:
> On Thu, Jun 6, 2024 at 5:29 PM Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
>>
>> On 2024-06-06 11:05, Alice Ryhl wrote:
>>> Make it possible to have Rust code call into tracepoints defined by C
>>> code. It is still required that the tracepoint is declared in a C
>>> header, and that this header is included in the input to bindgen.
>>>
>>> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
>>
>> [...]
>>
>>> diff --git a/rust/helpers.c b/rust/helpers.c
>>> index 2c37a0f5d7a8..0560cc2a512a 100644
>>> --- a/rust/helpers.c
>>> +++ b/rust/helpers.c
>>> @@ -165,6 +165,30 @@ rust_helper_krealloc(const void *objp, size_t new_size, gfp_t flags)
>>>    }
>>>    EXPORT_SYMBOL_GPL(rust_helper_krealloc);
>>>
>>> +void rust_helper_preempt_enable_notrace(void)
>>> +{
>>> +     preempt_enable_notrace();
>>> +}
>>> +EXPORT_SYMBOL_GPL(rust_helper_preempt_enable_notrace);
>>> +
>>> +void rust_helper_preempt_disable_notrace(void)
>>> +{
>>> +     preempt_disable_notrace();
>>> +}
>>> +EXPORT_SYMBOL_GPL(rust_helper_preempt_disable_notrace);
>>> +
>>> +bool rust_helper_current_cpu_online(void)
>>> +{
>>> +     return cpu_online(raw_smp_processor_id());
>>> +}
>>> +EXPORT_SYMBOL_GPL(rust_helper_current_cpu_online);
>>> +
>>> +void *rust_helper___rcu_dereference_raw(void **p)
>>> +{
>>> +     return rcu_dereference_raw(p);
>>> +}
>>> +EXPORT_SYMBOL_GPL(rust_helper___rcu_dereference_raw);
>>
>> Ouch. Doing a function call for each of those small operations will
>> have a rather large performance impact when tracing is active. If it is
>> not possible to inline those in Rust, then implementing __DO_TRACE in
>> a C function would at least allow Rust to only do a single call to C
>> rather than go back and forth between Rust and C.
>>
>> What prevents inlining those helpers in Rust ?
> 
> There's nothing fundamental that prevents it. But they contain a large
> amount of architecture specific code, which makes them a significant
> amount of work to reimplement in Rust.
> 
> For example, rcu_dereference_raw calls into READ_ONCE. READ_ONCE is
> usually a volatile load, but under arm64+LTO, you get a bunch of
> inline assembly that relies on ALTERNATIVE for feature detection:
> https://elixir.bootlin.com/linux/v6.9/source/arch/arm64/include/asm/rwonce.h#L36
> 
> And preempt_enable_notrace has a similar story.
> 
> The solution that Boqun mentions is nice, but it relies on rustc and
> clang using the same version of LLVM. You are unlikely to have
> compilers with matching LLVMs unless you intentionally take steps to
> make that happen.
> 
> But yes, perhaps these helpers are an argument to have a single call
> for __DO_TRACE instead.

If those helpers end up being inlined into Rust with the solution
pointed to by Boqun, then it makes sense to implement __DO_TRACE
in Rust. Otherwise doing a single call to C would be more efficient
than calling each of the helpers individually.

Thanks,

Mathieu

> 
> Alice

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com


  reply	other threads:[~2024-06-06 16:20 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-06 15:05 [PATCH 0/3] Tracepoints and static branch/call in Rust Alice Ryhl
2024-06-06 15:05 ` [PATCH 1/3] rust: add static_call support Alice Ryhl
2024-06-06 17:18   ` Peter Zijlstra
2024-06-06 19:09     ` Miguel Ojeda
2024-06-06 19:33       ` Peter Zijlstra
2024-06-07  9:43         ` Alice Ryhl
2024-06-07 10:52           ` Peter Zijlstra
2024-06-07 11:08             ` Alice Ryhl
2024-06-07 11:46             ` Miguel Ojeda
2024-06-06 15:05 ` [PATCH 2/3] rust: add static_key_false Alice Ryhl
2024-06-06 15:38   ` Mathieu Desnoyers
2024-06-06 16:19     ` Alice Ryhl
2024-06-06 17:23   ` Peter Zijlstra
2024-06-06 15:05 ` [PATCH 3/3] rust: add tracepoint support Alice Ryhl
2024-06-06 15:30   ` Mathieu Desnoyers
2024-06-06 15:49     ` Boqun Feng
2024-06-06 16:18       ` Mathieu Desnoyers
2024-06-06 17:35       ` Peter Zijlstra
2024-06-06 19:00         ` Boqun Feng
2024-06-06 19:29           ` Peter Zijlstra
2024-06-06 23:50             ` Boqun Feng
2024-06-06 16:16     ` Alice Ryhl
2024-06-06 16:21       ` Mathieu Desnoyers [this message]
2024-06-06 17:26   ` Peter Zijlstra
2024-06-06 15:25 ` [PATCH 0/3] Tracepoints and static branch/call in Rust Mathieu Desnoyers
2024-06-06 15:46   ` Alice Ryhl
2024-06-06 16:17     ` Mathieu Desnoyers

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=b36d92c8-6ce8-494f-951c-a6c24928f78d@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=a.hindborg@samsung.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=ardb@kernel.org \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=gary@garyguo.net \
    --cc=jbaron@akamai.com \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=wedsonaf@gmail.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).