On Mon, Dec 04, 2017 at 12:07:05PM +0000, Daniel P. Berrange wrote:
> On Mon, Dec 04, 2017 at 08:03:22PM +0800, Yang Zhong wrote:
> > On Fri, Dec 01, 2017 at 01:52:49PM +0100, Paolo Bonzini wrote:
> > > On 01/12/2017 11:56, Yang Zhong wrote:
> > > > This issue should be caused by much times of system call by
> > > > malloc_trim(),
> > > > Shannon's test script include 60 scsi disks and 31 ioh3420 devices.
> > > > We need
> > > > trade-off between VM perforamance and memory optimization. Whether
> > > > below
> > > > method is suitable?
> > > >
> > > > int num=1;
> > > > ......
> > > >
> > > > #if defined(CONFIG_MALLOC_TRIM)
> > > > if(!(num++%5))
> > > > {
> > > > malloc_trim(4 * 1024 * 1024);
> > > > }
> > > > #endif
> > > >
> > > > Any comments are welcome! Thanks a lot!
> > >
> > > Indeed something like this will do, perhaps only trim once per second?
> > >
> > Hello Paolo,
> >
> > Thanks for comments!
> > If we do trim once per second, maybe the frequency is a little high,
> > what'e
> > more, we need maintain one timer to call this, this also cost cpu
> > resource.
> >
> > I added the log and did the test here with my test qemu command, when VM
> > bootup,
> > which did more than 600 times free operations and 9 times memory trim in
> > rcu
> > thread. If i use our ClearContainer qemu command, the memory trim will
> > down
> > to 6 times. As for Shannon's test command, the malloc trim number will
> > abosultly
> > increse.
> >
> > In my above method, the trim is only executed in the multiple of 5, which
> > will
> > reduce trim times and do not heavily impact VM bootup performance.
> >
> > I also want to use synchronize_rcu() and free() to replace call_rcu(),
> > but this
> > method serialize to malloc() and free(), which will reduce VM performance.
> >
> > The ultimate aim is to reduce trim system call during the VM bootup and
> > running.
> > It's appreciated that if you have better suggestions.
>
> Does configuring QEMU to use tcmalloc or jemalloc instead of glibc's malloc
> give you the performance & menmory usage that you require? If so, it might
> not be worth bothering to hack around problems in glibc's malloc at all.
>
>
Hello Daniel,
Thanks for comment!
I used the tcmalloc and jemalloc to do compared test, it's pity that there is
no heap
item in smaps file with jemalloc, the glibc and tcmalloc result as below:
##glibc malloc
5618c0a98000-5618c1cde000 rw-p 00000000 00:00 0
[heap]
Size: 18712 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 10536 kB
Pss: 10536 kB
##tcmalloc
557f79119000-557f7af46000 rw-p 00000000 00:00 0
[heap]
Size: 30900 kB
Rss: 20244 kB
Pss: 20244 kB
The result show the Rss with tcmalloc is higher than glibc's.
Regards,
Yang
> Regards,
> Daniel
> --
> |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o- https://fstop138.berrange.com :|
> |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
