> On Tue, Jul 16, 2019 at 01:13:52PM +0100, Alex Bennée wrote:
>> The opcode decode tables aren't really part of the CPUPPCState but an
>> internal implementation detail for the translator. This can cause
>> problems with memcpy in cpu_copy as any table created during
>> ppc_cpu_realize get written over causing a memory leak. To avoid this
>> move the tables into PowerPCCPU which is better suited to hold
>> internal implementation details.
>>
>> Attempts to fix: https://bugs.launchpad.net/qemu/+bug/1836558
>> Cc: <email address hidden>
>> Signed-off-by: Alex Bennée <email address hidden>
>
> I've applied this now to ppc-for-4.2. If there's an argument for
> including it in 4.1 during hard freeze, you'll need to spell it out
> for me.
Well without:
Subject: [RFC PATCH for 4.1] linux-user: unparent CPU object before unref
Date: Tue, 16 Jul 2019 15:01:33 +0100
Message-Id: <email address hidden>
it doesn't matter as we never attempt to free the memory once a thread
is destroyed. This causes all linux-user guests that create and destroy
threads quickly to slowly leak memory. However due to the dynamic opcode
table ppc/ppc64-linux-user guests leak a lot faster than most, in the
order of ~50k each time a thread is created and destroyed.
However I'm happy to defer to you as the maintainer :-)
David Gibson <email address hidden> writes:
> On Tue, Jul 16, 2019 at 01:13:52PM +0100, Alex Bennée wrote: /bugs.launchpad .net/qemu/ +bug/1836558
>> The opcode decode tables aren't really part of the CPUPPCState but an
>> internal implementation detail for the translator. This can cause
>> problems with memcpy in cpu_copy as any table created during
>> ppc_cpu_realize get written over causing a memory leak. To avoid this
>> move the tables into PowerPCCPU which is better suited to hold
>> internal implementation details.
>>
>> Attempts to fix: https:/
>> Cc: <email address hidden>
>> Signed-off-by: Alex Bennée <email address hidden>
>
> I've applied this now to ppc-for-4.2. If there's an argument for
> including it in 4.1 during hard freeze, you'll need to spell it out
> for me.
Well without:
Subject: [RFC PATCH for 4.1] linux-user: unparent CPU object before unref
Date: Tue, 16 Jul 2019 15:01:33 +0100
Message-Id: <email address hidden>
it doesn't matter as we never attempt to free the memory once a thread linux-user guests leak a lot faster than most, in the
is destroyed. This causes all linux-user guests that create and destroy
threads quickly to slowly leak memory. However due to the dynamic opcode
table ppc/ppc64-
order of ~50k each time a thread is created and destroyed.
However I'm happy to defer to you as the maintainer :-)
--
Alex Bennée