DPDK patches and discussions
 help / color / mirror / Atom feed
From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
To: Lewis Donzis <lew@perftech.com>
Cc: dev <dev@dpdk.org>
Subject: Re: Including contigmem in core dumps
Date: Tue, 28 May 2024 09:55:03 +0300	[thread overview]
Message-ID: <20240528095503.7556d91e@sovereign> (raw)
In-Reply-To: <1771016800.166016.1716856484319.JavaMail.zimbra@donzis.com>

Hi Lewis,

2024-05-27 19:34 (UTC-0500), Lewis Donzis:
> I've been wondering why we exclude memory allocated by eal_get_virtual_area() from core dumps? (More specifically, it calls eal_mem_set_dump() to call madvise() to disable core dumps from the allocated region.) 
> 
> On many occasions, when debugging after a crash, it would have been very convenient to be able to see the contents of an mbuf or other object allocated in contigmem space. And we often avoid using the rte memory allocator just because of this. 
> 
> Is there any reason for this, or could it perhaps be a compile-time configuration option not to call madvise()? 

Memory reserved by eal_get_virtual_area() is not yet useful,
but it is very large, so by excluding it from dumps,
DPDK prevents dumps from including large zero-filled parts.

It also makes sense to call eal_mem_set_dump(..., false)
from eal_memalloc.c:free_seg(), because of --huge-unlink=never:
in this mode (Linux-only), freed segments are not cleared,
so if they were included into dump, it would be a lot of garbage data.

Newly allocated hugepages are not included into dumps
because this would make dumps very large by default.
However, this could be an opt-in as a runtime option if need be.


  reply	other threads:[~2024-05-28  6:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-28  0:34 Lewis Donzis
2024-05-28  6:55 ` Dmitry Kozlyuk [this message]
2024-05-28 13:19   ` Lewis Donzis

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=20240528095503.7556d91e@sovereign \
    --to=dmitry.kozliuk@gmail.com \
    --cc=dev@dpdk.org \
    --cc=lew@perftech.com \
    /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).