On Tue, Jun 10, 2014 at 01:29:06PM +0200, Paolo Bonzini wrote: > Il 10/06/2014 13:23, Michael S. Tsirkin ha scritto: > >On Tue, Jun 10, 2014 at 01:12:04PM +0200, Paolo Bonzini wrote: > >>Il 10/06/2014 11:59, Michael S. Tsirkin ha scritto: > >>>>>What's the point compared to memory-backend-ram? > >>>> > >>>>That you can use shared memory, for example together with vhost-user. > >>> > >>>I don't think it's a good idea until THP supports shared memory. > >> > >>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? 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. > >>We should not limit ourselves due to kernel bugs. > > > >Why not? Practically people do have to run this on some kernel, > >we should not use kernel in a way that it can't support well. > >Old firefox doing a ton of fsync commands and slowing > >the box to a crawl comes to mind as another example of this. > > Yes, and firefox doesn't say "no sorry can't do it" when running on such a > kernel (which is much worse than more expensive TLB misses). > > Paolo kernel can't speed up fsync. So IIRC instead, firefox switched to using renames instead of fsync. IMHO QEMU should do the same, look for a mechanism that kernel can support efficiently, instead of insisting on using a feature that it can't. -- MST