Re: fuse uring / wake_up on the same core

[Bernd Schubert <bschubert@ddn.com>]

On 3/25/23 08:08, K Prateek Nayak wrote:
> [You don't often get email from kprateek.nayak@amd.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hello Hillf,
> 
> On 3/25/2023 5:58 AM, Hillf Danton wrote:
>> On 24 Mar 2023 22:44:16 +0000 Bernd Schubert <bschubert@ddn.com>
>>> How much of hack is this patch?
>>
>> It adds a churn to my mind then another RFC [1] rises.
>>
>> Feel free to make it work for you and resend it.
>>
>> [1] Subject: [RFC PATCH 0/5] sched: Userspace Hinting for Task Placement
>>      https://lore.kernel.org/lkml/20220910105326.1797-1-kprateek.nayak@amd.com/
> 
> Thank you for pointing to my series.
> 
> Another possible way to tackle this is with a strategy Andrei is using in
> his "seccomp: add the synchronous mode for seccomp_unotify" series
> (https://lore.kernel.org/lkml/20230308073201.3102738-1-avagin@google.com/)
> 
> In patch 2, Andrei adds a WF_CURRENT_CPU that allows the task to always
> wake on the CPU where the waker is running.
> (https://lore.kernel.org/lkml/20230308073201.3102738-3-avagin@google.com/)
> 
> I believe Bernd's requirement calls for a a WF_PREV_CPU which always
> wakes up the task on the CPU where it previously ran. I believe you can
> modify fuse_request_end() (in fs/fuse/dev.c) to use the WF_PREV_CPU flag
> when waking the tasks on req->waitq
> 
> (P.S. I'm not familiar with the fuse subsystem but the comment
> "Wake up waiter sleeping in request_wait_answer()" in fuse_request_end()
> seems to suggest that is the right place to add this flag.)
> 
> Peter favored wake flag strategy of fixing wakeup target in a reply to an
> earlier version of Andrei's series
> (https://lore.kernel.org/lkml/Y8UgBnsaGDUJKH5A@hirez.programming.kicks-ass.net/)
> but I'll let Peter respond with what he thinks is the right way to tackle
> this.
> 

Thanks Hillf, Prateek and Peter! I'm going right now through Andrei's 
(will also check Prateek patches later). On the first glance 
WF_CURRENT_CPU is exactly what I need. At least for fuse/uring no need 
for another 'WF_PREV_CPU' flag - it goes and comes back to/from the ring 
on 'current' cpu and only switches on the final completion - staying on 
the current cpu is all we need. Will test these patches later today.


Thanks again,
Bernd