Re: [Qemu-devel] [PATCH v4 18/29] hostmem: add file-based HostMemoryBackend

[Michael S. Tsirkin]

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