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 B4130A0509; Wed, 6 Apr 2022 04:10:11 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 539B640E2D; Wed, 6 Apr 2022 04:10:11 +0200 (CEST) Received: from mail-vk1-f179.google.com (mail-vk1-f179.google.com [209.85.221.179]) by mails.dpdk.org (Postfix) with ESMTP id 24FD340DF6 for ; Wed, 6 Apr 2022 04:10:09 +0200 (CEST) Received: by mail-vk1-f179.google.com with SMTP id g41so492787vkd.4 for ; Tue, 05 Apr 2022 19:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartx-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yrea4PDixyD+AOXRw8SxLo/LQ3VyuRqM/ISVCyvIzKs=; b=8T7uBEp/dM3HX+yz9YclDFyK+IsIiNtPlS6StPPvIyXKdZPhbjZWG3XuVCniG4hs6u aVZSv97tiKibY7gdniuauMnptQ5lRiS70xuuCyBnzQgUwNZzPkeniqmyOJt4zU21gw57 kL8MK3Dba4XvP1M4YO3k0v+INE081gDEmAABThKKm1dEadmwwVOK12e0h95GE8T3Mj4d OoB75Dc+5emjSQuzdf+DNTzny1pm0BxyaaiZyaZgoRTwPQ+6TIDNhGMlRW0M63Qiv9FQ O41MYIUy+E283/0jWlIfAHTgO2/OTLCsPw4RdUqXNrLJqNaRPDTpqQbZ7bJAngaKsGLX UcMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yrea4PDixyD+AOXRw8SxLo/LQ3VyuRqM/ISVCyvIzKs=; b=uR0uzAdUpM4frnHWYV26ZHTcnpQrvinTP65Yno5qmN1GGeruvXdj6u/6lk+TR79AOM hLIgy+d9sV8GXFmjLot8Ej3zXPZW4haB11vEvYykuUE3ZDYZXbcf9AK3PSlZPVUEsdyv FV+1U0UXC2VxEKc7wdwMwbSjLWUDN4o8t9A5XTesv0XGghzZ81YtZK4el5IZ8M9gIHel DqyQdWFmo7ff4p/dNWIn8w165XmKU8kOODPpMP3Q3AXf2htEJVEuHgn7jeg+82rUSek3 hodoTzk6gtBkBmQz95lic+mDdAUOpEvuQXodpZlTQkZJlkHvZYdrVnuK9ZM8DTVuU/Kb urOA== X-Gm-Message-State: AOAM530B1Vc9FMNfWeuJA33RtN4k1i2tSz3a9lM7eylINl6DFRbvznZ0 NEvMMDfXvNWqSO7Dde61RvcxZi/nMlXBdCc//vGjLg== X-Google-Smtp-Source: ABdhPJx7nmc9+VzSDH2LumVR9jBW4D4aHv1t9jgGlcL7gnH+TwaUhsEMfSy527sJAXOPU9HE1BYK0TZBaQc4gyOBcIs= X-Received: by 2002:a05:6122:d0b:b0:343:1378:83ed with SMTP id az11-20020a0561220d0b00b00343137883edmr2379146vkb.9.1649211008790; Tue, 05 Apr 2022 19:10:08 -0700 (PDT) MIME-Version: 1.0 References: <20220308094125.2716847-1-fengli@smartx.comOD> <20220401091004.3227117-1-fengli@smartx.com> <20220405154655.60900b0d@hermes.local> In-Reply-To: <20220405154655.60900b0d@hermes.local> From: Li Feng Date: Wed, 6 Apr 2022 10:11:35 +0800 Message-ID: Subject: Re: [PATCH v2] eal/linux: enable the hugepage mem dump To: Stephen Hemminger Cc: Anatoly Burakov , dev Content-Type: text/plain; charset="UTF-8" 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 Wed, Apr 6, 2022 at 6:46 AM Stephen Hemminger wrote: > > On Fri, 1 Apr 2022 17:10:04 +0800 > Li Feng wrote: > > > These hugepages include important structures. we should dump these > > hugepages into a coredump file for debugging when generating a coredump. > > > > Signed-off-by: Li Feng > > --- > > lib/eal/linux/eal_memalloc.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/lib/eal/linux/eal_memalloc.c b/lib/eal/linux/eal_memalloc.c > > index f8b1588cae..93c4f396cf 100644 > > --- a/lib/eal/linux/eal_memalloc.c > > +++ b/lib/eal/linux/eal_memalloc.c > > @@ -677,6 +677,8 @@ alloc_seg(struct rte_memseg *ms, void *addr, int socket_id, > > __func__); > > #endif > > > > + eal_mem_set_dump(addr, alloc_sz, true); > > + > > huge_recover_sigbus(); > > > > ms->addr = addr; > > > Don't merge this patch as is please; it would cause a lot of pain > in a cloud environment. > > In our environment core dumps are collected (via systemd) and uploaded > to a central server. With this kind of change the processing would get > overloaded with multi-gigabyte core dump size. Probably couldn't even > save a core dump on these kind of smart nics. > > > This needs to be optional (from command line) and default to the current > behavior (not dumping huge pages). On Linux, just with this patch, the coredump will not include these hugepages which are shared, we should write 0x73 to /proc/self/coredump_filter. This is the coredump_filter explanation: Since kernel 2.6.23, the Linux-specific /proc/[pid]/coredump_filter file can be used to control which memory segments are written to the core dump file in the event that a core dump is performed for the process with the corresponding process ID. The value in the file is a bit mask of memory mapping types (see mmap(2)). If a bit is set in the mask, then memory mappings of the corresponding type are dumped; otherwise they are not dumped. The bits in this file have the following meanings: bit 0 Dump anonymous private mappings. bit 1 Dump anonymous shared mappings. bit 2 Dump file-backed private mappings. bit 3 Dump file-backed shared mappings. bit 4 (since Linux 2.6.24) Dump ELF headers. bit 5 (since Linux 2.6.28) Dump private huge pages. bit 6 (since Linux 2.6.28) Dump shared huge pages. bit 7 (since Linux 4.4) Dump private DAX pages. bit 8 (since Linux 4.4) Dump shared DAX pages. By default, the following bits are set: 0, 1, 4 (if the CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS kernel configuration option is enabled), and 5. This default can be modified at boot time using the coredump_filter boot option.