On Tue, Jun 10, 2014 at 01:43:27PM +0200, Paolo Bonzini wrote: > Il 10/06/2014 13:35, Michael S. Tsirkin ha scritto: > >>>>Why? For example it would be useful for testing on machines that you > >>>>don't > >>>>have root for, and that do not have a hugetlbfs mount point. For example > >>>>you could run the test case from the vhost-user's patches. > >>> > >>>Sounds useful, I guess we could allow this when running under qtest. > >> > >>Or TCG, or Xen. At this point, why single out KVM? > >> > >>(Also, "--enable-kvm -mem-path /dev/shm" works on 2.0, and it would be a > >>regression in 2.1). > > > >It prints > > fprintf(stderr, "Warning: path not on HugeTLBFS: %s\n", path); > > > >Correct? > > Yes. > > >I guess I agree then, hopefully the warning is enough. > >Maybe add an extra warning that performance will suffer. > > > >>>>THP is not a magic wand and you can get slowness from memory fragmentation > >>>>at any time. > >>> > >>>Right but there's a difference between "can get slowness when memory > >>>is overcommitted" and "will get slowness even on a mostly idle box". > >> > >>I would like to see the slowness on a real-world benchmark though. I > >>suspect in most scenarios it would not matter. > > > >Weird. Things like kernel build time are known to be measureably > >improved by using THP. > > Even measurable speedups in most scenarios would not matter. I don't care > if a kernel compile takes 2 minutes vs. 110 seconds (for a 10% speedup), > even though it's great that THP can speed up such a common task. > > Paolo
True. But I am not sure why would such a user play with vhost-user at all. That one seems to mostly be about using aggressive polling to drive down guest to guest latency. -- MST