From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B5061A00C3; Wed, 15 Dec 2021 16:46:57 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 368EE40688; Wed, 15 Dec 2021 16:46:57 +0100 (CET) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by mails.dpdk.org (Postfix) with ESMTP id 86AEF40041; Wed, 15 Dec 2021 16:46:55 +0100 (CET) Received: by mail-lf1-f48.google.com with SMTP id u3so44015807lfl.2; Wed, 15 Dec 2021 07:46:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Y9Ct2akuyjmvCwaXgHjVbQ+BoDKq1EjOQ0TRUQ4HEig=; b=mA+O5SIB6kyyXkPxvkp3EmwlOtCAswaenr8VOsxSWVYJ1rB4QL2OKikVI0+pvuJCbC 0tvqKMjHXVpA65jZN+oxPXyLwYAbQDr9mnygIpuzQrAZ+d/qhAY7x6uSJJOhhPdw4Ha0 H7jC2kUH6sY8uffAN1v4GUW6HYH1YfKlivOREpYHpUSU72nXFyvDWw0JfomRNb4Hn/Ja wwnRTSzFqkU/uI7klMQ0H4+n16A34sUplnuA5hJjKPxyBzD0efpXdL/62QQw+JcVEHcU tq0+4OgxabAFDzofd1WbEwwm35NsMKfFszdXkQNEN+Wi3r3tjhINpLCFfa/Lwo8qzNhR 8how== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Y9Ct2akuyjmvCwaXgHjVbQ+BoDKq1EjOQ0TRUQ4HEig=; b=UaZvWobhRj42uZ3+i0xK74kb1rnSNRCfcMOykcapXS+DVvhn8H78Vq9SN3IQv/Nf2V BTwxnYs/8YAF+SC0nm2tv1CS6ILhzuC3NgCbq2LPbNWvRlxTbxKTkZhSsBgZbGjmUGUF Rml0kUADisABfdNxY4W2Xervf2rsK0UoDn5npMi/6OHV8TOTl0g2K1KLYBTIInygXWS6 gItSBk4pjX0/Y6t6rBIfRyjNr/ogWO02HjS8psTdaP4pe7f162F8/kaZ4rS6f5t41JBf QmSsD5gtlLJX6EJnAwYX60CJvRtfkdqdTwxG4XUG0TheGwBldeyty9b1WaasKJc0Qr1W Rduw== X-Gm-Message-State: AOAM53190uKvGaIJbZL8JYmwTaLo6rRLZ6pG0r4N2ujDLW/2xAuUq8sU k/lFWZVLyXZkuPdg0ck/H3c= X-Google-Smtp-Source: ABdhPJzb9Sk8sHsSc/bFLBZw8DJm8jzvduQl6KpyZmKUzEookKqW/L7eo1yKfSxz7MYbLB2aN16pOQ== X-Received: by 2002:a19:5e59:: with SMTP id z25mr10577062lfi.686.1639583215009; Wed, 15 Dec 2021 07:46:55 -0800 (PST) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id t3sm20616lfe.65.2021.12.15.07.46.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Dec 2021 07:46:54 -0800 (PST) Date: Wed, 15 Dec 2021 18:46:54 +0300 From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com> To: Gaoxiang Liu <gaoxiangliu0@163.com> Cc: dev@dpdk.org, Anatoly Burakov <anatoly.burakov@intel.com>, liugaoxiang@huawei.com, stable@dpdk.org Subject: Re: [PATCH v3] eal: allow to exclude memseg from core dump Message-ID: <20211215184619.55056e72@sovereign> In-Reply-To: <20211214151850.1183-1-gaoxiangliu0@163.com> References: <20211214120817.1476-1-gaoxiangliu0@163.com> <20211214151850.1183-1-gaoxiangliu0@163.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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org 2021-12-14 23:18 (UTC+0800), Gaoxiang Liu: > Some DPDK application is allocated storage partition of 8G(or smaller) > If coredump happens, the application doesn't work because of > insufficient storage space. > The patch provides a config that means whether the memseg memory > is allowed to exclude from core dump. > The DPDK application can choose to open it according to the actual > situation. Does it need to be a DPDK option? If eal_mem_set_dump() is exposed as rte_mem_set_dump(), this feature can be implemented by the application using rte_mem_event_callback_register(). On Linux only and for all hugepages (not only DPDK ones), administrator can reset bits 5 and 6 of /proc/[pid]/core_filter to solve the task without any programming at all. https://man7.org/linux/man-pages/man5/core.5.html [...] > diff --git a/doc/guides/linux_gsg/linux_eal_parameters.rst b/doc/guides/linux_gsg/linux_eal_parameters.rst > index 74df2611b5..b6805bc6df 100644 > --- a/doc/guides/linux_gsg/linux_eal_parameters.rst > +++ b/doc/guides/linux_gsg/linux_eal_parameters.rst > @@ -93,6 +93,10 @@ Memory-related options > > Free hugepages back to system exactly as they were originally allocated. > > +* ``--memseg-dont-dump`` > + > + Allow to exclude memseg from core dump. > + "Memory segment" is something that is understood by programmers, not users. Suggesting --no-huge-dump, in line with --no-huge and --huge-unlink.