Messages in this thread | | | From | Bernd Schubert <> | Subject | Re: fuse uring / wake_up on the same core | Date | Mon, 27 Mar 2023 14:35:28 +0000 |
| |
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
| |