On (24/06/07 10:40), Nhat Pham wrote: > Personally, I'm not super convinced about class locks. We're > essentially relying on the post-compression size of the data to > load-balance the queries - I can imagine a scenario where a workload > has a concentrated distribution of post-compression data (i.e its > pages are compressed to similar-ish sizes), and we're once again > contending for a (few) lock(s) again. > > That said, I'll let the data tell the story :) We don't need a perfect > solution, just a good enough solution for now. Speaking of size class locks: One thing to mention is that zsmalloc merges size classes, we never have documented/claimed 256 size classe, the actual number is always much much lower. Each such "cluster" (merged size classes) holds a range of objects' sizes (e.g. 3504-3584 bytes). The wider the cluster's size range the more likely the (size class) lock contention is. Setting CONFIG_ZSMALLOC_CHAIN_SIZE to 10 or higher makes zsmalloc pool to be configured with more size class clusters (which means that clusters hold narrower size intervals).
