slqb: cap remote free list size
SLQB has a design flaw noticed by Yanmin Zhang when doing network packet stress testing. My intention with lockless slab lists had been to try to balance producer/consumer type activity on the object queues just at allocation-time with the producer and free-time with the consumer. But that breaks down if you have a huge number of objects in-flight and then free them after activity is reduced at the producer-side. Basically just objects being allocated on CPU0 are then freed by CPU1 but then rely on activity from CPU0 (or periodic trimming) to free them back to the page allocator. If there is infrequent activity on CPU0, then it can take a long time for the periodic trimming to free up unused objects. Fix this by adding a lock to the page list queues and allowing CPU1 to do the freeing work synchronously if queues get too large. It allows "nice" producer/consumer type patterns to still fit within the fast object queues, without the possibility to build up a lot of objects... The spinlock should not be a big problem for nice workloads, as it is at least an order of magnitude less frequent than an object allocation/free operation. Signed-off-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
Showing
Please register or sign in to comment