On 8/3/23, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, 3 Aug 2023 at 02:53, Mateusz Guzik <mjguzik@xxxxxxxxx> wrote:
>>
>> So yes, atomics remain expensive on x86-64 even on a very moden uarch
>> and their impact is measurable in a syscall like read.
>
> Well, a patch like this should fix it.
>
> I intentionally didn't bother with the alpha osf version of readdir,
> because nobody cares, but I guess we could do this in the header too.
>
> Or we could have split the FMODE_ATOMIC_POS bit into two, and had a
> "ALWAYS" version and a regular version, but just having a
> "fdget_dir()" made it simpler.
>
> So this - together with just reverting commit 20ea1e7d13c1 ("file:
> always lock position for FMODE_ATOMIC_POS") - *should* fix any
> performance regression.
>
That would do it, but I'm uneasy about the partially "gimped" status
of the fd the caller can't do anything about.
I read the thread and still don't get what is the real-world use case
for the thing, a real-world consumer to take a look at would be nice.
As noted in another e-mail, the entire lack of pos locking in stock
kernel is a transient ordeal -- there is a point where the "donor" is
guaranteed to not use it and spot the refcount > 1 for any future use,
using pos locking going forward.
Perhaps, and I'm really just spitballing here, almost all expected use
cases would be 100% fine without pos lock so it all works out as is.
Similarly, if the target is multithreaded it already works as well.
Those who expect "fully qualified" semantics would pass a flag
argument denoting it but would possibly wait indefinitely while the
target is blocked somewhere in the kernel and it is not known if it is
even using the fd. This very well may be a deal breaker though and may
be too cumbersome to implement for real use.
All that said, personally I would either go forward with a "full fix"
(probably not worth it) or take the L and lock for all fds.
--
Mateusz Guzik <mjguzik gmail.com>
