>> (i've Cc:-ed x264 benchmarking experts - in case i missed something) > > It definitely worth trying... nice idea. But we need glibc to increase > vm_end in 2M aligned chunk, otherwise we've to workaround it in the > kernel, for short lived allocations like gcc to take advantage of > this. I managed to get 200M of gcc (of ~500M total) of translate.o > into hugepages with two glibc params, but I want it all in transhuge > before I measure it. I'm running it on the workstation that had 1 day > and half of uptime and it's still building more packages as I write > this and running large vfs loads in /usr and maildir. > Just an FYI on this--if you're testing x264, it performs _all_ memory allocation on init and never mallocs again, so it's a good testbed for something that uses a lot of memory but doesn't malloc/free a lot. Jason -- 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>