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 9C251440F0; Tue, 28 May 2024 08:55:06 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 65A48402D2; Tue, 28 May 2024 08:55:06 +0200 (CEST) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by mails.dpdk.org (Postfix) with ESMTP id B03F340150 for ; Tue, 28 May 2024 08:55:05 +0200 (CEST) Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-52961b77655so553802e87.2 for ; Mon, 27 May 2024 23:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716879305; x=1717484105; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=04YPWuiVE/TrFB92YOGjAYcItyk2udv19CCKvRj/xGQ=; b=Tlg9/KoN6n//hjLx3HH9bYqcINR4uYnETB51gn7GO3zCW3kgsBP263NzKGmtTYTlor YlARX8JHSjK0ynseMde/bN2jIvYgpv+JSu8HRDjwldG/aRoo7d1/8fGBztpfGT/QTwN2 RT82a/gdAA4tZhHG0ewh7+A2iF/JRAE6LhXOfc+gIQg/M4+ZUWgG6Spi7nzpZPTTaQKS UYaor8bdC4fMpdpzvp/0yBo0Xwzmswhwta5ooRI8lD/+K3tFfqkJbcAGXTVTgaEtwaD9 9cglXC/C/uPsw5B4WIZ0kF9iK83uiCm+CbPZ2YaG2D5soiDmdH21DeToOF3ouoI7dv9n LxzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716879305; x=1717484105; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=04YPWuiVE/TrFB92YOGjAYcItyk2udv19CCKvRj/xGQ=; b=IrLtuGl45vWXO40oxq1euHZy5lbu7VnqJnGZmcSmtMdm795lXn5qYtr9L/vpF89J6H b4LHbae27FnR483xS7FazusWKkVhwKJX4q9gwgBjbBg14hy0YriZglIhp6a4vWhcSJgG gjuBTkGG244KH+Lp6Y5CaTX4G4335gQiuINfsCznr9cGD8cf4n+QqOxOdc5uQF1nnzCS t/0i+jz0RCqVIVdnSJKfjC5nBrU2NfXycEVA1RsvCOiIyRrYPMoIBgGeLMW1kOFSxr+5 o6cMZ+cvLtcSZziG947ZoLcSz+oOpKwFgtm0mldXgG4aWgAiOYUJTZ7GDvnkxxjklIa4 RJyA== X-Gm-Message-State: AOJu0Yx7IAPGIBAt6T55cKtFNBoiKJDe3MNld7mk8sXCwOnjZwLsFKE0 9Ajc1pDlI/usDulbIBYehWynkUtC857iwHXaXu1H14hc9qUDSQVvseb+yg== X-Google-Smtp-Source: AGHT+IHoO0/2KFNVPO0sNiVwFa+RMWUxHIi7c6dtE9fF9CBThyZ7qUwY001g79EVuM4QG612lJkvEg== X-Received: by 2002:ac2:5296:0:b0:522:1e16:1f17 with SMTP id 2adb3069b0e04-52966bad53amr5890105e87.65.1716879304788; Mon, 27 May 2024 23:55:04 -0700 (PDT) Received: from sovereign (broadband-109-173-110-33.ip.moscow.rt.ru. [109.173.110.33]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-529716df1fasm904135e87.308.2024.05.27.23.55.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 May 2024 23:55:04 -0700 (PDT) Date: Tue, 28 May 2024 09:55:03 +0300 From: Dmitry Kozlyuk To: Lewis Donzis Cc: dev Subject: Re: Including contigmem in core dumps Message-ID: <20240528095503.7556d91e@sovereign> In-Reply-To: <1771016800.166016.1716856484319.JavaMail.zimbra@donzis.com> References: <1771016800.166016.1716856484319.JavaMail.zimbra@donzis.com> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 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.