From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B19FB45BA3; Tue, 22 Oct 2024 17:57:45 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4B6DA4029B; Tue, 22 Oct 2024 17:57:45 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 4134440272 for ; Tue, 22 Oct 2024 17:57:43 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 10DAA206AE; Tue, 22 Oct 2024 17:57:42 +0200 (CEST) Content-class: urn:content-classes:message Subject: RE: Including contigmem in core dumps MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Oct 2024 17:57:40 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F80A@smartserver.smartshare.dk> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <20241022083926.355b8b16@hermes.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Including contigmem in core dumps Thread-Index: AdskmJdkvFMna2SwT+Ksmjx5kXNbFAAAfgdg References: <402897283.8962444.1729600888805.JavaMail.zimbra@donzis.com> <20241022174711.7862000d@sovereign> <20241022083926.355b8b16@hermes.local> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Stephen Hemminger" , "Dmitry Kozlyuk" Cc: "Lewis Donzis" , "dev" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Tuesday, 22 October 2024 17.39 >=20 > On Tue, 22 Oct 2024 17:47:11 +0300 > Dmitry Kozlyuk wrote: >=20 > > 2024-10-22 07:41 (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()? > > > > The commit that originally added madvise() argued that dumping > everything > > ended up in coredumps with "useless" data [non-mapped or unused > pages]: > > > > > = http://git.dpdk.org/dpdk/commit/?id=3Dd72e4042c5ebda7af81448b387af8218136= > 402d0 > > > > Dumping mapped pages sounds reasonable in many cases. > > Not in all cases admittedly: > > - legacy memory mode mapping a lot of pages that are not (yet) used; > > - if packet data is confidential while the app is not. > > > > The option to dump or not can easily be a runtime one. > > The safe default however seems to be "off". Please feel free to submit a patch adding an EAL command line parameter = to control core dump. > > > > In dynamic memory node (not FreeSBD, unfortunately) > > rte_mem_event_callback-register() may be used to call madvise(). > > Maybe DPDK should allow such callbacks in any mode > > and invoke them during initialization to make the above solution > universal. >=20 > It is not unusual to have 2 or 4 Gigabytes of huge pages mapped. > Many embedded systems do not have 6G of extra storage available for a > single core > dump, not to mention multiples. Plus any storage can be really slow on > embedded > systems. >=20 > And the common scenario on Linux is to use systemd to capture and > compress > core dumps.