Time  Nick       Message
06:03 lhofhansl  Hi all... Do we still need the ordered (fair) mutex added by #15151?
06:03 lhofhansl  I was looking into why loading a map from disk takes longer with multiple emerge thread. I tracked it back (in part) to the use of ordered_mutex for the env-lock.
06:03 lhofhansl  When I change that back to std::mutex, the load speed is pretty much identical between 1 emerge thread and 4 or 8 merge threads.
06:03 lhofhansl  Whereas with ordered_mutex 4 emerge thread slow the overall load time by about 16% and 8 thread slow loading by about 26%.
06:03 lhofhansl  We added ordered_mutex for a reason. Is that reason still valid?
06:03 ShadowBot  https://github.com/luanti-org/luanti/issues/15151 -- [no squash] Divorce map database locking from env lock by sfan5
06:04 lhofhansl  sfan5: FYI
09:19 sfan5      ~tell lhofhansl it exists because of this https://github.com/luanti-org/luanti/blob/87669f982c9d998ca68c86bb50fdb66a8a75fb87/src/server.cpp#L1157-L1172
09:19 ShadowBot  sfan5: OK.
09:28 sfan5      ~tell lhofhansl in particular the testing in #15151 (see also https://irc.luanti.org/minetest-dev/2024-09-25) needs to be repeated so this doesn't kill performance in Warr1024's case again
09:28 ShadowBot  sfan5: OK.
15:37 sfan5      rubenwardy: do you manually merge the weblate commits to the website or how?
15:37 sfan5      says " Push is turned off for Luanti/Website. " if I try it from weblate itself
15:37 rubenwardy manually by git pull weblate master
15:37 rubenwardy but it would be good to implement push
15:38 rubenwardy would have to look how to do it with github, I forget
17:36 lhofhansl  Does the yielding require fair locking? The yielding happens without the lock held (obviously), so at that time mostly (only?)  the emerge threads compete for the lock. In that case at least, I do not see an advantage in fair locking. When we do not yield it's perhaps more interesting. Since the emerge threads need to lock twice to make progress, they'd be more vulnerable to waiting when the main thread acquires the lock in th
17:36 lhofhansl  e. But I am not sure that justifies the fair locking.
17:37 sfan5      I don't know. needs to be tested.
17:38 lhofhansl  I briefly looked into read-write locks, but that'd require some significant refactoring to separate read and write access in the code.
17:39 lhofhansl  Should I file a draft-PR that reverts back to std::mutex, and then we can ask Warr1024 to give it a spin when they get time...?
17:41 sfan5      sure
18:01 lhofhansl  #16739
18:01 ShadowBot  https://github.com/luanti-org/luanti/issues/16739 -- Use std::mutex for the env lock (instead of ordered_mutex), for testing. by lhofhansl
18:01 lhofhansl  Warr1024: FYI in case you are around.
22:35 MTDiscord  <wsor4035> @Warr1024