Hi Joonsoo,
On 08/01/2016 05:55 PM, Joonsoo Kim wrote:
Your patch updates these counters not only when a slabs are created and
destroyed but also when object is allocated/freed from the slab. This
would hurt runtime performance.
The counters are not updated for each object allocation/free - only if
that allocation/free results in that slab moving from one list
(free/partial/full) to another.
> slab lists for gathering slabinfo stats, resulting in a dramatic
> performance improvement. We tested this after growing the dentry cache to
> 70GB, and the performance improved from 2s to 2ms.
Nice improvement. I can think of an altenative.
I guess that improvement of your change comes from skipping to iterate
n->slabs_full list. We can achieve it just with introducing only num_slabs.
num_slabs can be updated when a slabs are created and destroyed.
Yes, slabs_full is typically the largest list.
We can calculate num_slabs_full by following equation.
num_slabs_full = num_slabs - num_slabs_partial - num_slabs_free
Calculating both num_slabs_partial and num_slabs_free by iterating
n->slabs_XXX list would not take too much time.
Yes, this would work too. We cannot avoid traversal of slabs_partial,
and slabs_free is usually a small list, so this should give us similar
performance benefits. But having separate counters could also be useful
for debugging, like the ones defined under CONFIG_DEBUG_SLAB/STATS.
Won't that help?
Thanks,
Aruna
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>