On Sat, Apr 10, 2010 at 11:42:44PM +0300, Avi Kivity wrote: > 3-5% improvement. I had to tune khugepaged to scan more aggressively > since the run is so short. The working set is only ~100MB here though. We need to either solve it with a kernel workaround or have an environment var for glibc to do the right thing... The best I got so far with gcc is with, about half goes in hugepages with this but it's not enough as likely lib invoked mallocs goes into heap and extended 1M at time. export MALLOC_MMAP_THRESHOLD_=$[1024*1024*1024] export MALLOC_TOP_PAD_=$[1024*1024*1024] Whatever we do, it has to be possible to disable it of course with malloc debug options, or with electric fence of course, but it's not like the default 1M provides any benefit compared to growing it 2M aligned ;) so it's quite an obvious thing to address in glibc in my view. Then if it takes too much RAM on small systems echo madvise >/sys/kernel/mm/transparent_hugepage/enabled will retain the optimizations in qemu guest physical address space range or other bits that are guaranteed not to waste memory and that also are a must-have on embedded that have even smaller l2 caches and slower cpus where every optimization matters. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>