On Thu, Mar 31, 2022 at 10:47 PM Burakov, Anatoly <anatoly.bura...@intel.com> wrote: > > On 08-Mar-22 9:41 AM, 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 <fen...@smartx.com> > > --- > > 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..d7c2eb14a1 100644 > > --- a/lib/eal/linux/eal_memalloc.c > > +++ b/lib/eal/linux/eal_memalloc.c > > @@ -623,6 +623,8 @@ alloc_seg(struct rte_memseg *ms, void *addr, int > > socket_id, > > goto resized; > > } > > > > + eal_mem_set_dump(va, alloc_sz, true); > > + > > /* In linux, hugetlb limitations, like cgroup, are > > * enforced at fault time instead of mmap(), even > > * with the option of MAP_POPULATE. Kernel will send > > I am amicable to the idea of including allocated hugepage data in core > dumps, but even with that assumption, i think you're setting the dump > flag a little too early, and never cleanup if something fails down the line. > > Perhaps move this to the very end of the function, after we have > succeeded in creating a new segment?
Done in the v2, thanks. > > -- > Thanks, > Anatoly
