lkml.org 
[lkml]   [2023]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: fuse uring / wake_up on the same core
Date
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

\
 
 \ /
  Last update: 2023-03-27 16:36    [W:0.179 / U:1.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site