-
Notifications
You must be signed in to change notification settings - Fork 258
Add getcpu system call support for getting a NUMA node of the current thread
#1575
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 3 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -11,8 +11,8 @@ use core::{fmt, hash}; | |
| /// - [Linux] | ||
| /// | ||
| /// [Linux]: https://man7.org/linux/man-pages/man3/CPU_SET.3.html | ||
| /// [`sched_setaffinity`]: crate::thread::sched_setaffinity | ||
| /// [`sched_getaffinity`]: crate::thread::sched_getaffinity | ||
| /// [`sched_setaffinity`]: sched_setaffinity | ||
| /// [`sched_getaffinity`]: sched_getaffinity | ||
| #[repr(transparent)] | ||
| #[derive(Clone, Copy)] | ||
| pub struct CpuSet { | ||
|
|
@@ -159,3 +159,25 @@ pub fn sched_getaffinity(pid: Option<Pid>) -> io::Result<CpuSet> { | |
| pub fn sched_getcpu() -> usize { | ||
| backend::thread::syscalls::sched_getcpu() | ||
| } | ||
|
|
||
| /// `sched_getcpu()`—Get the CPU and NUMA node that the current thread is currently on. | ||
| /// | ||
| /// # Example | ||
| /// | ||
| /// ```rust | ||
| /// use rustix::thread::getcpu; | ||
| /// | ||
| /// let (core, numa_node) = getcpu(); | ||
| /// | ||
| /// println!("The current thread was on the {core} core and {numa_node} numa node."); | ||
| /// ``` | ||
| /// | ||
| /// # References | ||
| /// - [Linux] | ||
| /// | ||
| /// [Linux]: https://man7.org/linux/man-pages/man2/getcpu.2.html | ||
| #[cfg(linux_kernel)] | ||
| #[inline] | ||
| pub fn getcpu() -> (usize, usize) { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. According to the Linux docs, the values written by
Would it be better to reflect them here as I see that
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I tried to do the same as |
||
| backend::thread::syscalls::getcpu() | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason for
inline(never)here? It's already marked#[cold], which should have the desired effect. It a compiler decides it really wants to inline this, even given what we've told it, that seems fine.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am still sure that non-inlining provides a better performance, but I agree with both points: the difference is tiny and the compiler can do it as it wants. But I want to explicitly tell the compiler to generate exactly one call method for the calling this function that should be called only once. If you don't like this, I can't roll back this change. After all, the main goal of the PR is adding
getcpu.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not so sure, myself. In a compiler with hot/cold basic block partitioning, inlining and then moving the cold blocks away from the hot path achieves a similar result to not-inlining, except that the compiler can more easily use an effectively custom calling convention. I don't know how much it matters in the code in question here, but in general, I don't like prohibiting compilers from doing things unless I have specific reasons.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have removed this line.