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. > 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? -- Han-Wen Nienhuys - hanwenn@xxxxxxxxx - http://www.xs4all.nl/~hanwen
