On Thu, May 11, 2017 at 09:17:46AM +0300, Nikolay Borisov wrote: > The ->free_chunk_space variable is used to track the unallocated space and > access to it is protected by a spinlock, which is not used for anything else. In the past, the spinlock protected a larger critical section where the overcommit was calculated. This is not true anymore and the bare counter has been left. So yes, from that POV it's ok to switch it to the atomic. The spinlock-protected increment is valid in some cases where the overhead on atomics is higher, compared to uncontended lock (ie. rare updates). For architectures where the bare type can be updated atomically we could even avoid atomicX_t if the code semantics allows that. For 64bit types it's ok on x86_64, for 32bit we'd need preemption workarounds (similar to what inode::i_size does). So, I'm fine with switching to the atomic64_t, I don't see it used in performance critical code. Reviewed-by: David Sterba <dsterba@xxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
