> > And making filp_close() fully sync again is also really not great. > > The patch is not doing it. No, but you were referencing the proposed patch as an alternative in your commit message. > > Yes, we just did re-added the f_pos optimization because it may have had > > an impact. And that makes more sense because that was something we had > > changed just a few days/weeks before. > > > > I don't think perf tax on something becomes more sensible the longer > it is there. One does need to answer the question why it does suddenly become relevant after all these years though. The original discussion was triggered by fifo ordering in task work which led to a noticable regression and why it was ultimately reverted. The sync proposal for fput() was an orthogonal proposal and the conclusion was that it wasn't safe generally https://lore.kernel.org/all/20150905051915.GC22011@xxxxxxxxxxxxxxxxxx even though it wasn't a direct response to the patch you linked. Sure, for f_pos it was obvious when and how that happend. Here? It needs a bit more justification. If you care about it enough send a patch that just makes close(2) go sync. We'll stuff it in a branch and we'll see what LKP has to say about it or whether this gets lost in noise. I really don't think letting micro-benchmarks become a decisive factor for code churn is a good idea. And fwiw, yes, maybe the difference between close(2) and other parts doesn't matter for you but for use mortals that maintain a bunch more then just a few lines of code in file.c if you have a tiny collection of differences in behavior everywhere it adds up. The fact that you think it's irrelevant doesn't mean we have that luxury. That's not to say your patches haven't been useful. Not at all. The close_range() tweak was very much appreciated and that f_pos thing was good to fix as well.
