On Fri, 2009-01-23 at 10:22 -0500, Christoph Lameter wrote: >> No there is another way. Increase the allocator order to 3 for the >> kmalloc-8192 slab then multiple 8k blocks can be allocated from one of the >> larger chunks of data gotten from the page allocator. That will allow slub >> to do fast allocs. On Sat, Jan 24, 2009 at 4:55 AM, Zhang, Yanmin <yanmin_zhang@xxxxxxxxxxxxxxx> wrote: > After I change kmalloc-8192/order to 3, the result(pinned netperf UDP-U-4k) > difference between SLUB and SLQB becomes 1% which can be considered as fluctuation. Great. We should fix calculate_order() to be order 3 for kmalloc-8192. Are you interested in doing that? On Sat, Jan 24, 2009 at 4:55 AM, Zhang, Yanmin <yanmin_zhang@xxxxxxxxxxxxxxx> wrote: > But when trying to increased it to 4, I got: > [root@lkp-st02-x8664 slab]# echo "3">kmalloc-8192/order > [root@lkp-st02-x8664 slab]# echo "4">kmalloc-8192/order > -bash: echo: write error: Invalid argument That's probably because max order is capped to 3. You can change that by passing slub_max_order=<n> as kernel parameter. On Sat, Jan 24, 2009 at 4:55 AM, Zhang, Yanmin <yanmin_zhang@xxxxxxxxxxxxxxx> wrote: > Comparing with SLQB, it seems SLUB needs too many investigation/manual finer-tuning > against specific benchmarks. One hard is to tune page order number. Although SLQB also > has many tuning options, I almost doesn't tune it manually, just run benchmark and > collect results to compare. Does that mean the scalability of SLQB is better? One thing is sure, SLUB seems to be hard to tune. Probably because it's dependent on the page order so much. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
