Re: [PATCH v2] squashfs: avoid thundering-herd cache wakeups

[Usama Arif <usama.arif@linux.dev>]

On 09/08/2026 23:43, Phillip Lougher wrote:
> 
> 
> On 07/08/2026 18:24, Usama Arif wrote:
>> squashfs_cache_get() puts a task to sleep when its block is not cached
>> and every cache entry is busy.  Those sleeps are non-exclusive, so the
>> nr_exclusive == 1 budget squashfs_cache_put() has always passed to
>> wake_up() is inert and one release makes every waiter runnable.  A wakee
>> only returns to squashfs_cache_get() if it observes cache->unused before
>> the entry is reclaimed; later wakees see zero and re-queue inside
>> wait_event() without rescanning.  One freed entry satisfies exactly one
>> capacity waiter, so waking the rest is waste.
>>
>> On a Meta production host serving a Python web application from a
>> packaged squashfs image, a 30-second trace caught 1,045,132
>> cache-release wake calls and 19,511,556 wakeups: 18.7 per release,
>> although each release added only one reusable cache entry.  This was
>> causing significant spikes in CPU usage.
>>
>> Make the waits exclusive, enqueueing while still holding cache->lock so
>> that a concurrent lookup either sees the waiter queued or the waiter
>> sees the block that lookup publishes.  Two things follow.
>>
>> A wakee cannot be assumed to consume the entry it was woken for: it may
>> find its own block published meanwhile, share that entry, and leave the
>> freed one unclaimed.  So a wakee which shares hands its wakeup on to the
>> next waiter, as commit 0ddad21d3e99 ("pipe: use exclusive waits when
>> reading or writing") does with wake_next_reader.
>>
>> And a waiter can now sleep through a publication of the very block it
>> wants, which the old broadcast gave it repeated chances to notice.  So
>> waiters are keyed by block: publishing wakes every waiter for that block
>> (nr_exclusive == 0), freeing an entry wakes one.  That needs a custom
>> wake callback, like wake_page_function() in mm/filemap.c, which also
>> records which wakeup arrived so the handoff only fires for a capacity
>> wakee.
>>
>> Broadcast is kept where more than one task can proceed - every waiter
>> for a published block, and the wake_up_all() on entry->wait_queue - at
>> the cost of walking the queue under wait_queue.lock to test the key.
>> Waiters are now served FIFO with a scheduling round trip per handoff
>> hop, so per-waiter latency changes; the filebench run below is 4x
>> oversubscribed, where that should hurt most.
>>
>> Measured on a 32-CPU VM against a read-only squashfs (gzip,
>> DECOMP_MULTI_PERCPU, FILE_DIRECT, default 8 metadata / 3 fragment cache
>> entries) staged in tmpfs, page cache dropped each iteration to force
>> cold decompression:
>>
>>    elbencho, 64 threads
>>      metadata stat        700 ->  1320 files/s    1.9x
>>      small-file read       40 ->    60 MiB/s      1.5x
>>
>>    filebench, 128 threads, open+read+stat+close (mean of 3x 30s)
>>      throughput        11,314 -> 25,186 ops/s     2.2x
>>      sched:sched_wakeup  27.0 ->   4.55 per op    5.9x fewer
>>      context switches    37.2 ->   7.64 per op    4.9x fewer
>>
>> Wakeups and context switches are per operation, since the two runs did
>> 2.2x different amounts of work.  Workloads which never queue for a cache
>> entry gain no wakeups.
>>
>> Signed-off-by: Usama Arif <usama.arif@linux.dev>
>> ---
>>   fs/squashfs/cache.c          | 114 +++++++++++++++++++++++++++++++++--
>>   fs/squashfs/squashfs_fs_sb.h |   9 +++
>>   2 files changed, 117 insertions(+), 6 deletions(-)
> 
> Very nice performance improvement.  Thanks.
> 
> Reviewed-by: Phillip Lougher <phillip@squashfs.org.uk>
> 

Thanks Phillip!

Regards,
Usama