qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Lieven <pl@kamp.de>
To: Paolo Bonzini <pbonzini@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Fam Zheng <famz@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] Qemu and heavily increased RSS usage
Date: Thu, 23 Jun 2016 18:19:41 +0200	[thread overview]
Message-ID: <576C0C1D.9090709@kamp.de> (raw)
In-Reply-To: <48f0c4a6-8c26-446d-1dfd-c79da0c18707@redhat.com>

Am 23.06.2016 um 17:47 schrieb Paolo Bonzini:
>
> On 23/06/2016 17:31, Peter Lieven wrote:
>> Am 23.06.2016 um 17:21 schrieb Paolo Bonzini:
>>> On 23/06/2016 16:58, Peter Lieven wrote:
>>>> commit ba3f4f64b0e941b9e03568b826746941bef071f9
>>>> Author: Paolo Bonzini <pbonzini@redhat.com>
>>>> Date:   Wed Jan 21 12:09:14 2015 +0100
>>>>
>>>>       exec: RCUify AddressSpaceDispatch
>>>>
>>>>       Note that even after this patch, most callers of address_space_*
>>>>       functions must still be under the big QEMU lock, otherwise the
>>>> memory
>>>>       region returned by address_space_translate can disappear as soon as
>>>>       address_space_translate returns.  This will be fixed in the next
>>>> part
>>>>       of this series.
>>>>
>>>>       Reviewed-by: Fam Zheng <famz@redhat.com>
>>>>       Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>>>>
>>>> @Paolo, @Fam, any idea?
>>> When you use RCU, freeing stuff is delayed a bit.
>> define a bit?
>>
>> I face the issue that it seems (some) stuff is actually never freed...
> Can you confirm that with e.g. valgrind?  It could be that malloc has
> asked the kernel for more RSS and never released that, but QEMU did free
> the memory.

Valgrind does not see the increased RSS.

HEAD at 9d82b5a
(gdb) monitor leak_check summary any
==10988== LEAK SUMMARY:
==10988==    definitely lost: 392 bytes in 15 blocks
==10988==    indirectly lost: 3,824 bytes in 38 blocks
==10988==      possibly lost: 640 bytes in 2 blocks
==10988==    still reachable: 3,510,751 bytes in 8,898 blocks
==10988==         suppressed: 0 bytes in 0 blocks

HEAD at 79e2b9a
(gdb) monitor leak_check summary any
==8108== LEAK SUMMARY:
==8108==    definitely lost: 392 bytes in 15 blocks
==8108==    indirectly lost: 3,824 bytes in 38 blocks
==8108==      possibly lost: 640 bytes in 2 blocks
==8108==    still reachable: 3,510,975 bytes in 8,898 blocks
==8108==         suppressed: 0 bytes in 0 blocks

Mhh, so your idea could be right. But what to do now? The introduction of RCU obviously increases the short term RSS usage. But thats never corrected as
it seems.

I see this behaviour with kernel 3.19 and kernel 4.4

Peter

  reply	other threads:[~2016-06-23 16:19 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-21  8:21 [Qemu-devel] Qemu and heavily increased RSS usage Peter Lieven
2016-06-21 13:18 ` Dr. David Alan Gilbert
2016-06-21 15:12   ` Peter Lieven
2016-06-22 10:56     ` Stefan Hajnoczi
2016-06-22 19:55       ` Peter Lieven
2016-06-22 20:56         ` Peter Maydell
2016-06-24  9:37           ` Stefan Hajnoczi
2016-06-24  9:53             ` Peter Lieven
2016-06-24  9:57               ` Dr. David Alan Gilbert
2016-06-24  9:58             ` Peter Maydell
2016-06-24 10:45               ` Peter Lieven
2016-06-27 12:39                 ` Stefan Hajnoczi
2016-06-27 13:33                   ` Peter Lieven
2016-06-23  9:57   ` Peter Lieven
2016-06-24 22:57     ` Michael S. Tsirkin
2016-06-23 14:58   ` Peter Lieven
2016-06-23 15:00     ` Dr. David Alan Gilbert
2016-06-23 15:02       ` Peter Lieven
2016-06-23 15:21     ` Paolo Bonzini
2016-06-23 15:31       ` Peter Lieven
2016-06-23 15:47         ` Paolo Bonzini
2016-06-23 16:19           ` Peter Lieven [this message]
2016-06-23 16:53             ` Paolo Bonzini
2016-06-23 21:28               ` Peter Lieven
2016-06-24  4:10                 ` Paolo Bonzini
2016-06-24  8:11                   ` Peter Lieven
2016-06-24  8:20                     ` Paolo Bonzini
2016-06-24  8:45                       ` Peter Lieven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=576C0C1D.9090709@kamp.de \
    --to=pl@kamp.de \
    --cc=dgilbert@redhat.com \
    --cc=famz@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).