On 9/11/24 14:08, Han-Wen Nienhuys wrote: > On Wed, Sep 11, 2024 at 12:31 PM Bernd Schubert > <bernd.schubert@xxxxxxxxxxx> wrote: >> Ok, it was a bit hard to extract that information. Basically kernel >> behavior doesn't match your expectations and causes overhead. As I wrote >> in the evening, I think the behavior comes from static bool filldir64() >> (or other filldir functions) in fs.readdir.c. Oh, I just notice I had >> posted the wrong line, correct one should be here >> >> https://elixir.bootlin.com/linux/v6.10.9/source/fs/readdir.c#L350 > > Ah, I was already wondering, as I couldn't understand why your > previous code link was relevant. > >> As you can see, that is fs/readdir.c - not fuse alone. And I guess it is >> right to stop on a pending signal. For me a but surprising that the >> first entry is still accepted and only then the signal is checked. > > Do you know how old this behavior is? It would be great to not have to > write the kludge on my side, but if it has been out there for a long > time, I can't pretend the problem doesn't exist once it is fixed, as > it will still crop up if folks run things on older kernels. The > runtime for Go has been issuing SIGURG for preempted goroutines since > ~2020. Following git history, I think introduced here commit 1f60fbe7274918adb8db2f616e321890730ab7e3 Author: Theodore Ts'o <tytso@xxxxxxx> Date: Sat Apr 23 22:50:07 2016 -0400 ext4: allow readdir()'s of large empty directories to be interrupted > >> One option would be to ignore that signal in userspace before readdir >> and to reset after that? > > I am not sure what change you are suggesting here. Can you clarify? > I mean SIG_IGN, either at fuse server startup or at set in opendir and unset in closedir, the latter is rather ugly for multi threaded fuse server. Bernd
