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 080D745BA3; Tue, 22 Oct 2024 18:01:01 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BC7074029B; Tue, 22 Oct 2024 18:01:00 +0200 (CEST) Received: from smtp-gw.pt.net (smtp-gw.pt.net [206.210.192.15]) by mails.dpdk.org (Postfix) with ESMTP id 8A3F240272 for ; Tue, 22 Oct 2024 18:00:58 +0200 (CEST) X-ASG-Debug-ID: 1729612857-09411a490f2ddbb0001-TfluYd Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by smtp-gw.pt.net with ESMTP id wTFmrrybbbTry2dC (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 22 Oct 2024 11:00:57 -0500 (CDT) X-Barracuda-Envelope-From: lew@perftech.com X-Barracuda-Effective-Source-IP: mail.pt.net[206.210.194.11] X-Barracuda-Apparent-Source-IP: 206.210.194.11 Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 66576971E04; Tue, 22 Oct 2024 11:00:57 -0500 (CDT) Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavis, port 10032) with ESMTP id fbEtC0-0jON8; Tue, 22 Oct 2024 11:00:57 -0500 (CDT) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 06D2D971E00; Tue, 22 Oct 2024 11:00:57 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.pt.net 06D2D971E00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=perftech.com; s=B15A3A56-ABEA-11EE-9719-5F12F125680F; t=1729612857; bh=nBlW7U0uvt0mn0ecTCYSKJuFyGdoNq7AbtSefdajlRw=; h=Date:From:To:Message-ID:MIME-Version; b=U/MPYqCEBLLpsHM96dEir1Y37bb3uWCXCwjyXzHz/NokfaW+97VdEWS8bivkFy34i IOKGRU5YyaFFmQRsob1mWuJG4mO9HBSN+tQfyvDCU7RY1eciNTchjreBXlqoFbkClq A+41sNPOXid4ZtgO0RX5UzT5QaaqbQTLneUH4AdEVBVLh8xyhPpmBcqTwNPL5gBa/n o0hD0yBAWMBxuiX7uKDRt4XTJaPchFo3U5ZFzCq/mzjMuctMBFIRs91VBDuH9pf5Rv oXXsYhTllJ9EPM/0+RO3V/jwX/8G1ybFLLF0mX4ZFfnn319xmR9QoZJ7N7eM2v1QF4 khRDCMRKZnD3Q== X-Virus-Scanned: amavis at pt.net Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavis, port 10026) with ESMTP id 5vj9g8Cp1S9E; Tue, 22 Oct 2024 11:00:56 -0500 (CDT) Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by mail.pt.net (Postfix) with ESMTP id E6857971A7F; Tue, 22 Oct 2024 11:00:56 -0500 (CDT) Date: Tue, 22 Oct 2024 11:00:55 -0500 (CDT) From: Lewis Donzis To: Stephen Hemminger Cc: Dmitry Kozlyuk , dev Message-ID: <1265725412.9011449.1729612855836.JavaMail.zimbra@donzis.com> In-Reply-To: <20241022083926.355b8b16@hermes.local> References: <402897283.8962444.1729600888805.JavaMail.zimbra@donzis.com> <20241022174711.7862000d@sovereign> <20241022083926.355b8b16@hermes.local> Subject: Re: Including contigmem in core dumps MIME-Version: 1.0 X-ASG-Orig-Subj: Re: Including contigmem in core dumps Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: [206.210.194.11] X-Mailer: Zimbra 8.8.15_GA_4652 (ZimbraWebClient - GC130 (Mac)/8.8.15_GA_4652) Thread-Topic: Including contigmem in core dumps Thread-Index: HXstYTA9efrwMdwE6+ZDz2P6CBy9QQ== X-Barracuda-Connect: mail.pt.net[206.210.194.11] X-Barracuda-Start-Time: 1729612857 X-Barracuda-Encrypted: TLS_AES_256_GCM_SHA384 X-Barracuda-URL: https://smtp-gw.pt.net:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at pt.net X-Barracuda-Scan-Msg-Size: 2573 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.132148 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 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 ----- On Oct 22, 2024, at 10:39 AM, Stephen Hemminger stephen@networkplumber.org wrote: > On Tue, 22 Oct 2024 17:47:11 +0300 > Dmitry Kozlyuk wrote: > >> 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=d72e4042c5ebda7af81448b387af8218136402d0 >> >> 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". >> >> 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. > > 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. > > And the common scenario on Linux is to use systemd to capture and compress > core dumps. Totally agree. Most of the time, we wouldn't want this enabled because the core dumps would be huge, but in environments where we do have storage available, it can greatly help troubleshooting to be able to examine the contents of contigmem in the debugger. Unfortunately, on FreeBSD, we don't have the luxury of systemd's ability to do this, or even to compress the core dumps, although we do have ZFS compression on the local filesystem, which does a pretty decent job on on core dumps.