On 7/23/26 4:27 PM, Sven Göthel wrote: > As described: > <https://jausoft.com/cgit/cgit.git/commit/?id=4d8f593faf93b1043309e987823220a70f70a701> > > Or find it in <https://jausoft.com/cgit/cgit.git/log/>, > if I must revise it (bugs).
Just a more esoteric fix (for size_t > 64bit) in hash64_str_clipped, where it shall be `64<=b` not equal. <https://jausoft.com/cgit/cgit.git/commit/?id=aa80688b08c153eabfe5f7264cc10f0231faadc4> Other than that, I guess its fine. 3h run: - 402k files cached - 7.3GB - 5572 hash matches - 5099 hash collisions - with cache-size=16777215, 16M mask FFFFFF 3h run on another server - 97k files cached - 9.0GB - 971 hash matches - 260 hash collisions - with cache-size=16777215, 16M mask FFFFFF Hence the cache size FFFFFF does look usable. ++++ Other ideas for enhancements: - Store key-len in slot/lock file to avoid the memory strlen. One could also add a magic number. - Decouple hash-resolution (bits) from cache-size. This would allow better hash match usage, like using the full 64-bit hash. However, a cleanup task would need to remove the oldest while holding the lock. This could also be done by another process. which might be overkill for our little cgit? :) But it still sounds neat. ++++ Notes on the cache algo: Currently the code uses a kind of double-checked locking. However, with a cache-match we use the content w/o holding a lock to allow concurrent access. It is possible that another request could overwrite or delete this file due to hash-mismatch or expiration. I assume chances are very minimal for this to happen. In case the file doesn't exist or doesn't match the hash or is expired, it closes the slot and acquires the lock with the intention to re-write the slot. After having acquired the slot, we double check whether the slot matches and hasn't been expired - then we use the concurrently created slot. Otherwise the slot either didn't exist, has been expired or a hash collision happened and it will get re-written. Hence, in case we perform any write access, double check-locking is being used. Bottom line, thx for cgit and it was fun hacking. Cheers, ~Sven
