qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v4 18/29] hostmem: add file-based HostMemoryBackend
Date: Tue, 10 Jun 2014 14:48:28 +0300

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]