All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wanpeng Li <kernellwp@gmail.com>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Fam Zheng <famz@redhat.com>,
	"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] qemu core file size
Date: Tue, 7 Nov 2017 14:16:11 +0800	[thread overview]
Message-ID: <CANRm+CzH82=t-5YZySHtX9_Dc88nv-4L38+2tHOqc1v6WzPS2w@mail.gmail.com> (raw)
In-Reply-To: <f2d1d51e-16d4-ed20-cda2-fad6c7394cc0@ozlabs.ru>

2017-11-07 14:12 GMT+08:00 Alexey Kardashevskiy <aik@ozlabs.ru>:
> On 07/11/17 17:02, Wanpeng Li wrote:
>> Hi Alexey,
>> 2017-11-07 13:46 GMT+08:00 Alexey Kardashevskiy <aik@ozlabs.ru>:
>>> On 07/11/17 01:08, Paolo Bonzini wrote:
>>>> On 06/11/2017 13:18, Wanpeng Li wrote:
>>>>> 2017-11-06 20:02 GMT+08:00 Paolo Bonzini <pbonzini@redhat.com>:
>>>>>> On 06/11/2017 12:59, Fam Zheng wrote:
>>>>>>>>> Could you point out the patchset for the fix?
>>>>>>>> Between 447b0d0b9ee8a0ac216c3186e0f3c427a1001f0c and
>>>>>>>> 092aa2fc65b7a35121616aad8f39d47b8f921618.
>>>>>>> Not sure how these relate to the core size, but I've tested upstream
>>>>>>> (ec7a8bf0b8f7dc7288fe8745464ee8217528cc6c) and with dump-guest-core=off the core
>>>>>>> file is 363M, still significantly larger than rss (~73M).
>>>>>>>
>>>>>>> What is bloating the core file?
>>>>>>
>>>>>> My guess would have been fragmented heap.  The core file, unlike the
>>>>>> RSS, includes all the mmaped memory (e.g. from shared libraries) that
>>>>>> has never been used.
>>>>>>
>>>>>> For example, all the Ceph/Gluster/PulseAudio/SPICE/whatever libraries
>>>>>> are included in the core file but likely are not in the RSS.
>>>>>
>>>>> Do you mean not use Memory API will avoid the fragmented heap?
>>>>
>>>> The high memory usage from the memory API causes excessive
>>>> fragmentation.  Alexey's work should help reducing memory usage and thus
>>>> the fragmentation.
>>>
>>> Since centos6 does not have this issue and centos7 does, I'd suggest
>>> MALLOC_ARENA_MAX&co
>>> https://www.gnu.org/software/libc/manual/html_node/Memory-Allocation-Tunables.html
>>
>> Thanks for the inputs. What's the recommend glibc.malloc.arena_max
>> value from you? :)
>
> I have no idea, you have to try different values as you are the one who is
> unhappy about the sizes :) I do not normally mess with this as things
> should just work with the defaults whatever they are.
>
>
>>
>>>
>>> glibc changed some defaults between rhel/centos 6 and 7 if I recall
>>> correctly, and these arenas now create big anon mappings per thread, these
>>> are not really touched (so they do not use resident memory) but may appear
>>> in these dumps, dunno.
>>>
>>> btw do you configure the machine to make "kill -11" produce qemu core dumps?
>>
>> Yeah, some tuning in /etc/libvirt/qemu.conf, max_core="unlimited",
>> dump_guest_core=0
>
> dump_guest_core=0 should mean "no dumps", no?
> Do you know how to enable this without libvirt?

Please add dump_guest_core=off in your qemu command-line,
"dump_guest_core" mean not dump guest memory and just dump qemu
itself.

Regards,
Wanpeng Li

  reply	other threads:[~2017-11-07  6:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-06  9:11 [Qemu-devel] qemu core file size Wanpeng Li
2017-11-06  9:41 ` Paolo Bonzini
2017-11-06 10:01   ` Wanpeng Li
2017-11-06 10:26     ` Paolo Bonzini
2017-11-06 11:59       ` Fam Zheng
2017-11-06 12:02         ` Paolo Bonzini
2017-11-06 12:18           ` Wanpeng Li
2017-11-06 14:08             ` Paolo Bonzini
2017-11-07  1:22               ` Wanpeng Li
2017-11-07  5:46               ` Alexey Kardashevskiy
2017-11-07  6:02                 ` Wanpeng Li
2017-11-07  6:12                   ` Alexey Kardashevskiy
2017-11-07  6:16                     ` Wanpeng Li [this message]
2017-11-07  7:00                       ` Alexey Kardashevskiy

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='CANRm+CzH82=t-5YZySHtX9_Dc88nv-4L38+2tHOqc1v6WzPS2w@mail.gmail.com' \
    --to=kernellwp@gmail.com \
    --cc=aik@ozlabs.ru \
    --cc=famz@redhat.com \
    --cc=pbonzini@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.