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 4EC47A034F for ; Thu, 25 Feb 2021 19:24:36 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D2B161608D6; Thu, 25 Feb 2021 19:24:05 +0100 (CET) Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) by mails.dpdk.org (Postfix) with ESMTP id 2C6C41608B8 for ; Thu, 25 Feb 2021 19:24:05 +0100 (CET) Received: by mail-lj1-f171.google.com with SMTP id m11so6732783lji.10 for ; Thu, 25 Feb 2021 10:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CNJydT+/0RlL7HEjSEh4Ay8+LtDCdHYqtHlctF+dITU=; b=U1ATeDISERQJVfRvuo0DuGAd+1f841xEwtyqJX1Elaa00vTgNkczpFpVZMJV1Sq5H8 qtWJOLv/k6cXwy50QhCVChM3aXTyLm0Te0eBu8nQNFMXBK84lcW2KaLz+iMcV5PojV0g t7TpzgUCxS30AjpXZdXve2Epp8yH9NlZWcCeSsHpKwnPZe7+rE3A/FOfOQXzXjHfSQct e/JMWvkRiQzlLpcT9+EHkjiw6SS1c35A1JpvZhgCzaHzCXo/ADRjSPmqbW4q3skO8ASZ 2kZknuMf7JiHUku0IBqR1jIq68aeMb20XLgLIGCP/qPiii1q8HBHvv3Gu+OkHSzOPd0J HlkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CNJydT+/0RlL7HEjSEh4Ay8+LtDCdHYqtHlctF+dITU=; b=ri81w6buDohMqNKWm3886pH+jnUKN+3eQWJNTIDk08unGWwoPrdy0FOdiDwO4Eqg6O bbxuZQG3S4ww9bGytSbqu07LZT/qfbZyh40b94/w5TNnU0cv8NCf9sfdv/vOi9RgkDLL g5grE7FnTHVdNCyd5zwKmVb9hX2GuUnFnevjE4Wa/RNkHXW+bY2r2oJNDEsyql76HlnU aa5mGxMFDtHeYFIsfdO5YmXT8twqg0eiCCwfwL3WbjboVDK9pLN1QOuaknY+E4f8hXg5 Mwhebg4YO9l2egpbuw0e3wEKvaXcIohaKIjHBHoEVotDAqgD9CxqGk8QxJOqVdfntw4n NBUw== X-Gm-Message-State: AOAM53236O2NC2nFpAL/eIzcjHN+UOJhpPjZmxAecdLk+Q+Ds9lPVaYi aX9UnjP7QWAPSCXCEJa9dsgKePuvfNGw7stMvjE= X-Google-Smtp-Source: ABdhPJz5JEF6I4XzOs6NuxztfZk7SCYH/5+M61t8IOZlMxAJhC1+O0+vCawRP9Kje7l4vMdLEM27JJv1Q9FfhAG7i/0= X-Received: by 2002:a2e:780d:: with SMTP id t13mr2323272ljc.382.1614277444720; Thu, 25 Feb 2021 10:24:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: James Huang Date: Thu, 25 Feb 2021 10:23:53 -0800 Message-ID: To: Li Feng Cc: users@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [dpdk-users] DPDK program huge core file size X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" UPDATE: yes, the code works, in use of system api madvise(). Regards, James Huang On Thu, Feb 25, 2021 at 9:37 AM James Huang wrote: > > @feng, thank you for the info. We'll pull the fix from > eal_common_memory.c:eal_get_virtual_area(), give it a try. > > Regards, > James Huang > > > On Tue, Feb 23, 2021 at 8:00 PM Li Feng wrote: > >> I think you should update your dpdk to the latest. >> I have fixed this issue some months ago. >> >> d72e4042c - mem: exclude unused memory from core dump >> >> Thanks, >> Feng Li >> >> James Huang =E4=BA=8E2021=E5=B9=B42=E6=9C=8824=E6= =97=A5=E5=91=A8=E4=B8=89 =E4=B8=8A=E5=8D=883:22=E5=86=99=E9=81=93=EF=BC=9A >> > >> > UPDATE: the 'kill -6' command does not dump the hugepage memory zone >> into >> > the core file. >> > >> > Is there a way to bypass the hugepage memory zone dump into the core >> file >> > with running gcore command ? >> > >> > >> > On Fri, Feb 19, 2021 at 11:18 AM James Huang >> wrote: >> > >> > > On CentOS7, we observed that the program (based on dpdk 19.11) >> creates a >> > > huge core file size, i.e. 100+GB, far bigger than the expected <4GB. >> even >> > > though the system only installs 16GB memory, and allocates 1GB >> hugepage >> > > size at boot time. no matter if the core file is created by program >> panic >> > > (segfault), or run with tool gcore. >> > > >> > > On CentOS 6, the program (based on dpdk 17.05), the core file is the >> > > expected size. >> > > >> > > On CentOS7, we tried to adjust the process coredump_filter >> combinations, >> > > it found only when clean the bit 0 can avoid the huge core size, >> however, a >> > > cleared bit 0 generate small core file (200MB) and is meaningless fo= r >> debug >> > > purposes, i.e. gdb bt command does not output. >> > > >> > > Is there a way to avoid dumping the hugepage memory, while remaining >> other >> > > memory in the core file? >> > > >> > > The following is the program pmap output comparison. >> > > on CentOS 6, the hugepage resides on the process user space: >> > > ... >> > > 00007f4e80000000 1048576K rw-s- /mnt/huge_1GB/rtemap_0 >> > > 00007f4ec0000000 2048K rw-s- >> > > /sys/devices/pci0000:00/0000:00:02.0/0000:04:00.0/resource0 >> > > 00007f4ec0200000 16K rw-s- >> > > /sys/devices/pci0000:00/0000:00:02.0/0000:04:00.0/resource4 >> > > 00007f4ec0204000 2048K rw-s- >> > > /sys/devices/pci0000:00/0000:00:02.0/0000:04:00.1/resource0 >> > > 00007f4ec0404000 16K rw-s- >> > > /sys/devices/pci0000:00/0000:00:02.0/0000:04:00.1/resource4 >> > > ... >> > > >> > > >> > > on CentOS 7, the hugepage resides on the process system space:: >> > > ... >> > > 0000000100000000 20K rw-s- config >> > > 0000000100005000 184K rw-s- fbarray_memzone >> > > 0000000100033000 4K rw-s- fbarray_memseg-1048576k-0-0 >> > > 0000000140000000 1048576K rw-s- rtemap_0 >> > > 0000000180000000 32505856K r---- [ anon ] >> > > 0000000940000000 4K rw-s- fbarray_memseg-1048576k-0-1 >> > > 0000000980000000 33554432K r---- [ anon ] >> > > 0000001180000000 4K rw-s- fbarray_memseg-1048576k-0-2 >> > > 00000011c0000000 33554432K r---- [ anon ] >> > > 00000019c0000000 4K rw-s- fbarray_memseg-1048576k-0-3 >> > > 0000001a00000000 33554432K r---- [ anon ] >> > > 0000002200000000 1024K rw-s- resource0 >> > > 0000002200100000 16K rw-s- resource3 >> > > 0000002200104000 1024K rw-s- resource0 >> > > 0000002200204000 16K rw-s- resource3 >> > > ... >> > > >> > > Thanks, >> > > -James >> > > >> >