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 B8FEA44099; Tue, 28 May 2024 15:19:25 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A46DF402E4; Tue, 28 May 2024 15:19:25 +0200 (CEST) Received: from smtp-gw.pt.net (smtp-gw.pt.net [206.210.192.15]) by mails.dpdk.org (Postfix) with ESMTP id 685E6402E4 for ; Tue, 28 May 2024 15:19:24 +0200 (CEST) X-ASG-Debug-ID: 1716902362-09411a0f023ae730001-TfluYd Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by smtp-gw.pt.net with ESMTP id bnFaUpqYGjMzHtvd (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 28 May 2024 08:19:22 -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 A929411B410D; Tue, 28 May 2024 08:19:22 -0500 (CDT) Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavis, port 10032) with ESMTP id wZsHwNICQLGK; Tue, 28 May 2024 08:19:22 -0500 (CDT) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 6528A11B3F57; Tue, 28 May 2024 08:19:22 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.pt.net 6528A11B3F57 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=perftech.com; s=B15A3A56-ABEA-11EE-9719-5F12F125680F; t=1716902362; bh=MgUPZDN2pI8ijBiOfE7kcKjtFcWkAB+xwbB0wf2Ce6w=; h=Date:From:To:Message-ID:MIME-Version; b=KPq8xrW5c1YxZi+5MQa58JCgZ36zTzEkg7v6WDcHeEAP+JaVO9Yh4n6JNSMbDS97k d0cXavvD4FK2iv73tSnzjz/+oCxCNOtSch4M0+6TBTG6CPkpFUh47XpSTHie9jWusM YrfRux1virBDC17M3e14P4kxrl4dSTxNDpN8MwuR0C6QNmn+EHFwEiZ6TUcsPGvZsH Ypeb3miZOa9IUBm/KHKneU5/qKpnDFSF5eQXP2q1MDhsq1Qqqghbkdnxm21t1ILAzz lVbmW842fyeI1rzkovlXufnF+s/WzfYG8UE0Qjy30AM+cJeiJqzrYrXJ1IZP9BZ83S 4tNiv15ch0hDw== 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 eL-DK5A5H44j; Tue, 28 May 2024 08:19:22 -0500 (CDT) Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by mail.pt.net (Postfix) with ESMTP id 5270C11B3FD7; Tue, 28 May 2024 08:19:22 -0500 (CDT) Date: Tue, 28 May 2024 08:19:22 -0500 (CDT) From: Lewis Donzis To: Dmitry Kozlyuk Cc: dev Message-ID: <936080190.226277.1716902362160.JavaMail.zimbra@donzis.com> In-Reply-To: <20240528095503.7556d91e@sovereign> References: <1771016800.166016.1716856484319.JavaMail.zimbra@donzis.com> <20240528095503.7556d91e@sovereign> 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_4581 (ZimbraWebClient - GC125 (Mac)/8.8.15_GA_4581) Thread-Topic: Including contigmem in core dumps Thread-Index: ryLat17gDLNS08E+QmNRojCUlLmTmQ== X-Barracuda-Connect: mail.pt.net[206.210.194.11] X-Barracuda-Start-Time: 1716902362 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: 1712 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.125461 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 May 28, 2024, at 1:55 AM, Dmitry Kozlyuk dmitry.kozliuk@gmail.com wrote: > Hi Lewis, > > 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. Thanks for the clarification. I agree that not including freed segments makes perfect sense. But when debugging a core dump, it's sometimes really helpful to be able to see what's in the mbuf that was being processed at the time. Perhaps it would be a useful option to be able to tell the allocator not to disable core dumps. In the mean time, my experiments to get around this have not been fruitful. I wondered if we could enable core dumps for mbufs by calling rte_mempool_mem_iter() on the pool returned by rte_pktmbuf_pool_create(), and have the callback function call madvise(memhdr->addr, memhdr->len, MADV_CORE). But that didn't help, or at least the size of the core file didn't increase. I then tried disabling the call to madvise() in the DPDK source code, and that didn't make any difference either. Note that this is on FreeBSD, so I wonder if there's some fundamental reason that the contigmem memory doesn't get included in a core dump?