> On Mon, Feb 05, 2024 at 02:22:29PM +0800, JonasZhou wrote: > > As I expected, your test is exercising the contention case rather > than the single, uncontended case. As such, your patch is simply > optimising the structure layout for the contended case at the > expense of an extra cacheline miss in the uncontended case. > > I'm not an mm expert, so I don't know which case we should optimise > for. > > However, the existing code is not obviously wrong, it's just that > your micro-benchmark exercises the pathological worst case for the > optimisation choices made for this structure. Whether the contention > case is worth optimising is the first decision that needs to be > made, then people can decide if hacking minor optimisations into the > code is better than reworking the locking and/or algorithm to avoid > the contention altogether is a better direction... According to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=unixbench, many people use Unixbench and submit optimization patches to Linux based on its scores. So this is not my micro-benchmark exercises. When multiple processes open the same file, such as multiple processes opening libc.so, there will be contention. > -Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
