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 7047F45BA3; Tue, 22 Oct 2024 17:39:31 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F1EDA40616; Tue, 22 Oct 2024 17:39:30 +0200 (CEST) Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by mails.dpdk.org (Postfix) with ESMTP id A23CB4029B for ; Tue, 22 Oct 2024 17:39:29 +0200 (CEST) Received: by mail-pg1-f175.google.com with SMTP id 41be03b00d2f7-7ea16c7759cso3152449a12.1 for ; Tue, 22 Oct 2024 08:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1729611569; x=1730216369; 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=HEOc9RRit6+Xo/SJkedOnL97PbxmBlzvyeCvdt4eeag=; b=SjZHvAWxPx06OJyBczT6D+KIVD6RUDbHtx9KbIewWSLwfEn5BQGliFM0L0Rc3dSgIs +W+b7Zhe7zVU/biiBAIeosI03RUpeZyuyfkns3wcrMqIVvcGUI8Xc7oSyDDugFRgMro1 kXoZcBzE4T30xCzpZUwhoIEMlDwTP1X+87ZBbONmicZAWi+tCGDedIAVKL+u/ZejDti9 P9WcwltwnIe/oVUjuZDjC+hG+X/QsSs7EuftfA2RWtfV3bmzxisKnBpLMDBOykEr862B 2lyHT/ldkIuhB97JUuas0s4l3w2+qECUfWyYL5bR1vXSlunrUlBLDAMG10pIEOCFnSBU NlSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729611569; x=1730216369; 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=HEOc9RRit6+Xo/SJkedOnL97PbxmBlzvyeCvdt4eeag=; b=VwjyGjgJBd1QHS1xTt81desbNAZEHxk9ut9lMRawx4AKvWeI3Ht9JtgPLi8UVfz3MY VsOnXgdHcn9E+f42LgepCHXJZ9vwZb/zFbctdhDmM1+K/G62lfFSy8ONYOChywgyVE4+ 5Tif+KOaCo8y5vGUU7InGua2cJv0Zf3mHnpnfXSUGpVw+8LhNg+b449l1qu/vVQfkYIM ARXC0CQtDQ/nY4lDrEwl5pSAkuno3xiwvzq1cuni2xiA5aHaXTejMB8Q118TASiTdC3R qM3iPfWQIK2EIk7uLWaAkHOmqN4P+0SoTb98Xr9pttZrc2Pd7kW7drlZyk6FzM4cRZiM sN7w== X-Forwarded-Encrypted: i=1; AJvYcCXIH2XA1YOnMV58nK6l3h6Jt3DVIaI4jvLvwM3ZnCqtYtlQHLx+d/3fLLiMNpXWw4In0/s=@dpdk.org X-Gm-Message-State: AOJu0YxD1A8c1gccAGJumxwcV8ax3b0GciRxi2CsOR3Uj9lDVLEjtB19 w8C2S0fT8n/XGhfMrvbSnRkeL5VRIM/sb7DfbGvgWQ9iJaiNT5o21HoplmuIbak= X-Google-Smtp-Source: AGHT+IEHWGOg5adUTb0H9zbwDOl83T/2Id33OE2bBeM0gmABW8vYlyFIkdbDAZlz7JL7vmGt34yzgw== X-Received: by 2002:a05:6a21:1789:b0:1d9:2705:699e with SMTP id adf61e73a8af0-1d96de8703bmr3315796637.7.1729611568600; Tue, 22 Oct 2024 08:39:28 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71ec13342besm4866625b3a.55.2024.10.22.08.39.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Oct 2024 08:39:28 -0700 (PDT) Date: Tue, 22 Oct 2024 08:39:26 -0700 From: Stephen Hemminger To: Dmitry Kozlyuk Cc: Lewis Donzis , dev Subject: Re: Including contigmem in core dumps Message-ID: <20241022083926.355b8b16@hermes.local> In-Reply-To: <20241022174711.7862000d@sovereign> References: <402897283.8962444.1729600888805.JavaMail.zimbra@donzis.com> <20241022174711.7862000d@sovereign> 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 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.