From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52113) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHq79-0008Q3-BR for qemu-devel@nongnu.org; Tue, 28 Jun 2016 06:19:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHq73-0004LA-Ah for qemu-devel@nongnu.org; Tue, 28 Jun 2016 06:19:30 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:55407 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHq73-0004L4-0g for qemu-devel@nongnu.org; Tue, 28 Jun 2016 06:19:25 -0400 References: <1467104499-27517-1-git-send-email-pl@kamp.de> <1467104499-27517-12-git-send-email-pl@kamp.de> From: Peter Lieven Message-ID: <57724F26.3010903@kamp.de> Date: Tue, 28 Jun 2016 12:19:18 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 11/15] qom: use mmap for bigger Objects List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , Kevin Wolf , Max Reitz , Paolo Bonzini , "Michael S. Tsirkin" , "Dr. David Alan Gilbert" , Gerd Hoffmann Am 28.06.2016 um 12:10 schrieb Peter Maydell: > On 28 June 2016 at 10:01, Peter Lieven wrote: >> Signed-off-by: Peter Lieven >> --- >> include/qom/object.h | 1 + >> qom/object.c | 20 +++++++++++++++++--- >> 2 files changed, 18 insertions(+), 3 deletions(-) >> >> diff --git a/include/qom/object.h b/include/qom/object.h >> index 2f8ac47..c612f3a 100644 >> --- a/include/qom/object.h >> +++ b/include/qom/object.h >> @@ -400,6 +400,7 @@ struct Object >> GHashTable *properties; >> uint32_t ref; >> Object *parent; >> + size_t instance_size; >> }; >> >> /** >> diff --git a/qom/object.c b/qom/object.c >> index 9743ea4..203162b 100644 >> --- a/qom/object.c >> +++ b/qom/object.c >> @@ -15,6 +15,7 @@ >> #include "qom/object.h" >> #include "qom/object_interfaces.h" >> #include "qemu/cutils.h" >> +#include "qemu/mmap-alloc.h" >> #include "qapi/visitor.h" >> #include "qapi-visit.h" >> #include "qapi/string-input-visitor.h" >> @@ -453,6 +454,12 @@ static void object_deinit(Object *obj, TypeImpl *type) >> } >> } >> >> +static void object_munmap(void *opaque) >> +{ >> + Object *obj = opaque; >> + qemu_anon_ram_munmap(obj, obj->instance_size); >> +} >> + >> static void object_finalize(void *data) >> { >> Object *obj = data; >> @@ -467,16 +474,23 @@ static void object_finalize(void *data) >> } >> } >> >> +#define OBJECT_MMAP_THRESH 4096 >> + >> Object *object_new_with_type(Type type) >> { >> Object *obj; >> >> g_assert(type != NULL); >> type_initialize(type); >> - >> - obj = g_malloc(type->instance_size); >> + if (type->instance_size < OBJECT_MMAP_THRESH) { >> + obj = g_malloc(type->instance_size); >> + obj->free = g_free; >> + } else { >> + obj = qemu_anon_ram_mmap(type->instance_size); >> + obj->free = object_munmap; >> + } >> + obj->instance_size = type->instance_size; >> object_initialize_with_type(obj, type->instance_size, type); >> - obj->free = g_free; > This one I disagree with. We should trust the platform malloc > implementation (or g_malloc() in this case), or get it fixed > if it is broken somehow. The ptmalloc implementation can only return memory back to the kernel if there is unallocated memory at the end of the heap. Every hole in between cannot be returned. But I agree I would appreciate if malloc would handle this. Some Objects we allocate are very large. E.g. some are 70kB as far as I remember. Peter