[Devel] [PATCH VZ10 v3] fs/fuse: revamp fuse_invalidate_files() to avoid blocking the userspace evloop
Konstantin Khorenko
khorenko at virtuozzo.com
Fri May 15 18:07:33 MSK 2026
In the meanwhile i will commit the current version of the patch, please develop incremental ones
addressing the points you decide important.
On 5/15/26 15:56, Alexey Kuznetsov wrote:
> 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.
More information about the Devel
mailing list