[Devel] [PATCH VZ10 v3] fs/fuse: revamp fuse_invalidate_files() to avoid blocking the userspace evloop

[Alexey Kuznetsov]

On Fri, May 15, 2026 at 9:26 PM Konstantin Khorenko
<khorenko at virtuozzo.com> wrote:
> In fuse_inval_files_work() you print fi->inode - FUSE_ROOT_ID
> and said this is intentional to sync with userspace valies.
>
> Why then here we don't subtract FUSE_ROOT_ID as well?

Yup. Opus said me the same thing but I did not care. We have mess all
over all the code because linux vfs inode number and internal vstorage
inode number are off by one and I do not even remember when to
subtract and when to add, got used to deal with this. :-) Frankly, I
would prefer
not to do these adjustments at all, it makes text shorter, and does
not actually affect
the work.

>    Each fuse_conn has its own delayed_work (fc->inval_files_work), but the global workqueue runs only
> one work item at a time across all connections.

Also was noticed by Opus. I decided it is actually good thing to keep
it in one thread. No need
to additionally overload cpus when they are already overloaded. This
is background job
triggered when VM has already died in fatal disaster most likely
because of critical cpu overload.
I find it unreasonable to hug more cpus for this massive work and risk
to trigger global shaman event.
Of course, this can be not correct, but intuition tells me this is
right decision,
some delay of recovery is not a good argument against, since we must
throttle down actually.

>From the other hand, WQ_UNBOUND does not sound unreasonable.
Kui Liu, can we invent a test to check this? Maybe it is worth to add
module option
like I did for worker_flags/cpu_worker_flags to allow to experiment
with these things?

What bothers me more now: I have no idea what WQ_MEM_RECLAIM is,
never used it, never even looked at this. It sounds scary.