2022-04-05 15:46 (UTC-0700), Stephen Hemminger: > On Fri, 1 Apr 2022 17:10:04 +0800 > Li Feng <fen...@smartx.com> 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..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).
Maybe expose eal_mem_set_dump() as rte_mem_set_dump()? This would allow to implement the feature easily using memory callbacks. Better, one can enable hugepages to dump selectively: for example, dump some interesting hash tables but skip rings and mempools.
