On 04/11/2010 02:00 PM, Ingo Molnar wrote:
Did you make sure to check your stddev on those?
I'm doing another run to look at variability.
Sigh. Could you please stop using stone-age tools like /usr/bin/time and
instead use:
I did one more run for each setting and got the same results (within a
second).
Yes, i know we had a big flamewar about perf kvm, but IMHO that is no reason
for you to pretend that this tool doesnt exist ;-)
I use it almost daily, not sure why you think I pretend it doesn't exist.
Is this something realistic or just a benchmark thing?
I'd suggest for you to use the default settings, to make it realistic. (Maybe
also 'advanced/high-quality' settings that an advanced user would utilize.)
In fact I'm guessing --ultrafast would reduce the gain. The lower the
quality, the less time you spend looking at other frames to find
commonality. Like bzip2 -1/-9 memory footprint.
It is no doubt that benchmark advantages can be shown - the point of this
exercise is to show that there are real-life speedups to various categories of
non-server apps that hugetlb gives us.
I think hugetlb will mostly help server apps. Desktop apps simply don't
have working sets big enough to matter. There will be exceptions, but
as a rule, desktop apps won't benefit much from this.
--
error compiling committee.c: too many arguments to function
--
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>