Wake up another thread synchronously.

This method behaves like `notify_one`, except that it hints to the
scheduler that the current thread is about to go to sleep, so it should
schedule the target thread on the same CPU.

This is used by Rust Binder as a performance optimization. When sending
a transaction to a different process, we usually know which thread will
handle it, so we can schedule that thread for execution next on this
CPU for better cache locality.

Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
 rust/kernel/sync/condvar.rs | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/rust/kernel/sync/condvar.rs b/rust/kernel/sync/condvar.rs
index b679b6f6dbeb..9861c6749ad0 100644
--- a/rust/kernel/sync/condvar.rs
+++ b/rust/kernel/sync/condvar.rs
@@ -155,6 +155,12 @@ fn notify(&self, count: i32, flags: u32) {
         };
     }
 
+    /// Calls the kernel function to notify one thread synchronously.
+    pub fn notify_sync(&self) {
+        // SAFETY: `wait_list` points to valid memory.
+        unsafe { bindings::__wake_up_sync(self.wait_list.get(), bindings::TASK_NORMAL) };
+    }
+
     /// Wakes a single waiter up, if any.
     ///
     /// This is not 'sticky' in the sense that if no thread is waiting, the notification is lost

-- 
2.43.0.rc2.451.g8631bc7472-goog

On 12/6/23 11:09, Alice Ryhl wrote:
> Wake up another thread synchronously.
> 
> This method behaves like `notify_one`, except that it hints to the
> scheduler that the current thread is about to go to sleep, so it should
> schedule the target thread on the same CPU.
> 
> This is used by Rust Binder as a performance optimization. When sending
> a transaction to a different process, we usually know which thread will
> handle it, so we can schedule that thread for execution next on this
> CPU for better cache locality.
> 
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
>  rust/kernel/sync/condvar.rs | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/rust/kernel/sync/condvar.rs b/rust/kernel/sync/condvar.rs
> index b679b6f6dbeb..9861c6749ad0 100644
> --- a/rust/kernel/sync/condvar.rs
> +++ b/rust/kernel/sync/condvar.rs
> @@ -155,6 +155,12 @@ fn notify(&self, count: i32, flags: u32) {
>          };
>      }
> 
> +    /// Calls the kernel function to notify one thread synchronously.
> +    pub fn notify_sync(&self) {
> +        // SAFETY: `wait_list` points to valid memory.
> +        unsafe { bindings::__wake_up_sync(self.wait_list.get(), bindings::TASK_NORMAL) };

I took a look at the C function (i.e. __wake_up_common) and there I
found this:

    lockdep_assert_held(&wq_head->lock);

So I think this function requires that the lock is held, how are you
ensuring this?

-- 
Cheers,
Benno

On Thu, Dec 7, 2023 at 9:22 PM Benno Lossin <benno.lossin@proton.me> wrote:
>
> On 12/6/23 11:09, Alice Ryhl wrote:
> > Wake up another thread synchronously.
> >
> > This method behaves like `notify_one`, except that it hints to the
> > scheduler that the current thread is about to go to sleep, so it should
> > schedule the target thread on the same CPU.
> >
> > This is used by Rust Binder as a performance optimization. When sending
> > a transaction to a different process, we usually know which thread will
> > handle it, so we can schedule that thread for execution next on this
> > CPU for better cache locality.
> >
> > Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> > ---
> >  rust/kernel/sync/condvar.rs | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/rust/kernel/sync/condvar.rs b/rust/kernel/sync/condvar.rs
> > index b679b6f6dbeb..9861c6749ad0 100644
> > --- a/rust/kernel/sync/condvar.rs
> > +++ b/rust/kernel/sync/condvar.rs
> > @@ -155,6 +155,12 @@ fn notify(&self, count: i32, flags: u32) {
> >          };
> >      }
> >
> > +    /// Calls the kernel function to notify one thread synchronously.
> > +    pub fn notify_sync(&self) {
> > +        // SAFETY: `wait_list` points to valid memory.
> > +        unsafe { bindings::__wake_up_sync(self.wait_list.get(), bindings::TASK_NORMAL) };
>
> I took a look at the C function (i.e. __wake_up_common) and there I
> found this:
>
>     lockdep_assert_held(&wq_head->lock);
>
> So I think this function requires that the lock is held, how are you
> ensuring this?

No, we don't need to hold a lock. The call stack is:

1. __wake_up_sync
2. __wake_up_sync_key
3. __wake_up_common_lock
4. __wake_up_common

And __wake_up_common_lock will lock wq_head->lock before calling
__wake_up_common.

Alice

On 12/8/23 08:29, Alice Ryhl wrote:
> On Thu, Dec 7, 2023 at 9:22 PM Benno Lossin <benno.lossin@proton.me> wrote:
>>
>> On 12/6/23 11:09, Alice Ryhl wrote:
>>> Wake up another thread synchronously.
>>>
>>> This method behaves like `notify_one`, except that it hints to the
>>> scheduler that the current thread is about to go to sleep, so it should
>>> schedule the target thread on the same CPU.
>>>
>>> This is used by Rust Binder as a performance optimization. When sending
>>> a transaction to a different process, we usually know which thread will
>>> handle it, so we can schedule that thread for execution next on this
>>> CPU for better cache locality.
>>>
>>> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
>>> ---
>>>  rust/kernel/sync/condvar.rs | 6 ++++++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/rust/kernel/sync/condvar.rs b/rust/kernel/sync/condvar.rs
>>> index b679b6f6dbeb..9861c6749ad0 100644
>>> --- a/rust/kernel/sync/condvar.rs
>>> +++ b/rust/kernel/sync/condvar.rs
>>> @@ -155,6 +155,12 @@ fn notify(&self, count: i32, flags: u32) {
>>>          };
>>>      }
>>>
>>> +    /// Calls the kernel function to notify one thread synchronously.
>>> +    pub fn notify_sync(&self) {
>>> +        // SAFETY: `wait_list` points to valid memory.
>>> +        unsafe { bindings::__wake_up_sync(self.wait_list.get(), bindings::TASK_NORMAL) };
>>
>> I took a look at the C function (i.e. __wake_up_common) and there I
>> found this:
>>
>>     lockdep_assert_held(&wq_head->lock);
>>
>> So I think this function requires that the lock is held, how are you
>> ensuring this?
> 
> No, we don't need to hold a lock. The call stack is:
> 
> 1. __wake_up_sync
> 2. __wake_up_sync_key
> 3. __wake_up_common_lock
> 4. __wake_up_common
> 
> And __wake_up_common_lock will lock wq_head->lock before calling
> __wake_up_common.

Seems like I just looked at the wrong function.

Reviewed-by: Benno Lossin <benno.lossin@proton.me>

-- 
Cheers,
Benno

On 12/6/23 07:09, Alice Ryhl wrote:
> Wake up another thread synchronously.
> 
> This method behaves like `notify_one`, except that it hints to the
> scheduler that the current thread is about to go to sleep, so it should
> schedule the target thread on the same CPU.
> 
> This is used by Rust Binder as a performance optimization. When sending
> a transaction to a different process, we usually know which thread will
> handle it, so we can schedule that thread for execution next on this
> CPU for better cache locality.
> 
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> [...]
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>