On Fri, Nov 17, 2017 at 01:54:09PM +0000, Stefan Hajnoczi wrote: > On Fri, Nov 17, 2017 at 02:23:34PM +0800, Yang Zhong wrote: > > diff --git a/util/rcu.c b/util/rcu.c > > index ca5a63e..8d491a6 100644 > > --- a/util/rcu.c > > +++ b/util/rcu.c > > @@ -26,6 +26,7 @@ > > * IBM's contributions to this file may be relicensed under LGPLv2 or > > later. > > */ > > > > +#include <malloc.h> > > This header file is not mentioned in the C99 standard or POSIX. It is > probably not available on all host OSes that QEMU supports. Please use > #ifdef CONFIG_LINUX. > > > #include "qemu/osdep.h" > > #include "qemu-common.h" > > #include "qemu/rcu.h" > > @@ -272,6 +273,9 @@ static void *call_rcu_thread(void *opaque) > > node->func(node); > > } > > qemu_mutex_unlock_iothread(); > > +#ifdef CONFIG_LINUX > > + malloc_trim(0); > > +#endif > > It is important that the rcu thread isn't overzealous in minimizing heap > size if that means ordinary malloc(3) calls will experience latency > spikes. Please leave a few MB free so that malloc(3) doesn't take the > slow path.
If you pass '0' the docs say that the minimum amount is left in the heap, per M_TOP_PAD, which is 128kb. Strangely the mallopt(3) man page suggests, that free() should automatically trim the heap when its size exceeds M_TOP_TRIM, which is again 128kb by default. So I'm puzzelled by malloc_trim() would be needed unless there are scenarios in which free() won't trim, that aren't mentioned in the manpage. Also, how does malloc_trim interact with tcmalloc.so that people often use in preference to glibc's built in malloc ? 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 :|
