> SLUB can also take advantage of the larger page sizes. A kernel compile is > already ~5-10% faster with 16k. This will increase the speed even more. It > will also increase the effectiveness of slab reclaim because more objects > can be processed with a single acquisition of the dcache or inode lock. I just built a 64K pagesize + SLUB kernel for my build system (4 socket Montecito) and then used it to rebuild all my standard config kernels. Comparing against a set of builds with a 16K pagesize + SLAB, the results were a lot less impressive than implied by this and the "set SLUB as default" postings. Seven out of eleven builds were faster, but only by 3-6 seconds (around 3% on a three minute build). Three builds were slower (by a similar margin). So I'd only rate the performance change as a "possible win, probably doesn't hurt much" on this small system. News from the performance team at Intel is also pretty guarded. You've fixed the performance regressions we saw with earlier versions of SLUB for Netperf and Volanomark. Our favourite online transaction processing benchmark is currently up about 1% against mainline+SLAB (though this is just reclaiming the loss that SLAB has incurred since RHEL5 split off). What do the big system numbers look like that have you so excited about SLUB? -Tony - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|