* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory [not found] <20200420070508.645533-1-fengli@smartx.com> @ 2020-04-20 7:07 ` Li Feng 2020-04-20 7:13 ` David Marchand 2020-04-23 15:43 ` [dpdk-dev] [PATCH v2] " Li Feng 1 sibling, 1 reply; 19+ messages in thread From: Li Feng @ 2020-04-20 7:07 UTC (permalink / raw) To: Anatoly Burakov; +Cc: lifeng1519, Kyle Zhang, dev Add cc dev@dpdk.org Thanks, Feng Li Li Feng <fengli@smartx.com> 于2020年4月20日周一 下午3:04写道: > > Avoid dump all mmapped memory to coredump file when crash. > Otherwise it will very large and it's hard to analyze with gdb. > > In my test, it will dump 128GiB memory to coredump file when integrated > to spdk with default configuration. > > Signed-off-by: Li Feng <fengli@smartx.com> > --- > lib/librte_eal/common/eal_common_memory.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c > index cc7d54e0c..cc6743d56 100644 > --- a/lib/librte_eal/common/eal_common_memory.c > +++ b/lib/librte_eal/common/eal_common_memory.c > @@ -102,6 +102,13 @@ eal_get_virtual_area(void *requested_addr, size_t *size, > if (mapped_addr == MAP_FAILED && allow_shrink) > *size -= page_sz; > > + if (mapped_addr != MAP_FAILED) { > + if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0) > + RTE_LOG(INFO, EAL, "MADV_DONTDUMP advice setting failed.\n"); > + RTE_LOG(DEBUG, EAL, "madvise with MADV_DONTDUMP, addr: %p size: %ld\n", > + mapped_addr, (size_t)map_sz); > + } > + > if (mapped_addr != MAP_FAILED && addr_is_hint && > mapped_addr != requested_addr) { > try++; > -- > 2.11.0 > -- The SmartX email address is only for business purpose. Any sent message that is not related to the business is not authorized or permitted by SmartX. 本邮箱为北京志凌海纳科技有限公司(SmartX)工作邮箱. 如本邮箱发出的邮件与工作无关,该邮件未得到本公司任何的明示或默示的授权. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory 2020-04-20 7:07 ` [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory Li Feng @ 2020-04-20 7:13 ` David Marchand 2020-04-20 9:40 ` Feng Li 0 siblings, 1 reply; 19+ messages in thread From: David Marchand @ 2020-04-20 7:13 UTC (permalink / raw) To: Li Feng; +Cc: Anatoly Burakov, lifeng1519, Kyle Zhang, dev On Mon, Apr 20, 2020 at 9:10 AM Li Feng <fengli@smartx.com> wrote: > Li Feng <fengli@smartx.com> 于2020年4月20日周一 下午3:04写道: > > > > Avoid dump all mmapped memory to coredump file when crash. > > Otherwise it will very large and it's hard to analyze with gdb. > > > > In my test, it will dump 128GiB memory to coredump file when integrated > > to spdk with default configuration. Can you test with current master which has this change? https://git.dpdk.org/dpdk/commit?id=8a4baf06c17a806696fb10aba36fce7471983028 Thanks. -- David Marchand ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory 2020-04-20 7:13 ` David Marchand @ 2020-04-20 9:40 ` Feng Li 2020-04-21 7:41 ` David Marchand 0 siblings, 1 reply; 19+ messages in thread From: Feng Li @ 2020-04-20 9:40 UTC (permalink / raw) To: David Marchand; +Cc: Li Feng, Anatoly Burakov, Kyle Zhang, dev Thank you, Marchand, I have just tested your patch, and it doesn't work. The core dump file is still very very large, the same to virtual memory size. David Marchand <david.marchand@redhat.com> 于2020年4月20日周一 下午3:13写道: > > On Mon, Apr 20, 2020 at 9:10 AM Li Feng <fengli@smartx.com> wrote: > > Li Feng <fengli@smartx.com> 于2020年4月20日周一 下午3:04写道: > > > > > > Avoid dump all mmapped memory to coredump file when crash. > > > Otherwise it will very large and it's hard to analyze with gdb. > > > > > > In my test, it will dump 128GiB memory to coredump file when integrated > > > to spdk with default configuration. > > Can you test with current master which has this change? > https://git.dpdk.org/dpdk/commit?id=8a4baf06c17a806696fb10aba36fce7471983028 > > Thanks. > > -- > David Marchand > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory 2020-04-20 9:40 ` Feng Li @ 2020-04-21 7:41 ` David Marchand 2020-04-21 11:06 ` Feng Li 0 siblings, 1 reply; 19+ messages in thread From: David Marchand @ 2020-04-21 7:41 UTC (permalink / raw) To: Feng Li, Anatoly Burakov; +Cc: Li Feng, Kyle Zhang, dev On Mon, Apr 20, 2020 at 11:41 AM Feng Li <lifeng1519@gmail.com> wrote: > > Thank you, Marchand, David is fine. > > I have just tested your patch, and it doesn't work. > The core dump file is still very very large, the same to virtual memory size. Please double check that the patch is in. I remember checking coredump size with my patch. This needs more investigation but I don't have time atm. Anatoly, opinion? -- David Marchand ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory 2020-04-21 7:41 ` David Marchand @ 2020-04-21 11:06 ` Feng Li 2020-04-21 12:19 ` Burakov, Anatoly 0 siblings, 1 reply; 19+ messages in thread From: Feng Li @ 2020-04-21 11:06 UTC (permalink / raw) To: David Marchand; +Cc: Anatoly Burakov, Li Feng, Kyle Zhang, dev, fanyang Hi David, Mmap with PROT_NONE does not affected the core dump size. Here is a simple test prog: #include <sys/mman.h> #include <time.h> #include <stdint.h> #include <unistd.h> #include <stdlib.h> #include <stdio.h> int main(int argc, char** argv) { // FIXME(fengli): XXXXX uint64_t gb = atoi(argv[1]); void* ptr = mmap(0, gb << 30, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (ptr == (void*)-1) { perror("[-] mmap failed with MAP_PRIVATE | MAP_ANONYMOUS"); exit(1); } while(1) sleep(1); return 0; } Thanks. David Marchand <david.marchand@redhat.com> 于2020年4月21日周二 下午3:41写道: > > On Mon, Apr 20, 2020 at 11:41 AM Feng Li <lifeng1519@gmail.com> wrote: > > > > Thank you, Marchand, > > David is fine. > > > > > I have just tested your patch, and it doesn't work. > > The core dump file is still very very large, the same to virtual memory size. > > Please double check that the patch is in. > I remember checking coredump size with my patch. > > This needs more investigation but I don't have time atm. > Anatoly, opinion? > > > -- > David Marchand > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory 2020-04-21 11:06 ` Feng Li @ 2020-04-21 12:19 ` Burakov, Anatoly 2020-04-21 16:38 ` Feng Li 0 siblings, 1 reply; 19+ messages in thread From: Burakov, Anatoly @ 2020-04-21 12:19 UTC (permalink / raw) To: Feng Li, David Marchand; +Cc: Li Feng, Kyle Zhang, dev, fanyang On 21-Apr-20 12:06 PM, Feng Li wrote: > #include <sys/mman.h> > #include <time.h> > #include <stdint.h> > #include <unistd.h> > #include <stdlib.h> > #include <stdio.h> > > int main(int argc, char** argv) { > // FIXME(fengli): XXXXX > uint64_t gb = atoi(argv[1]); > void* ptr = mmap(0, gb << 30, PROT_NONE, MAP_PRIVATE | > MAP_ANONYMOUS, -1, 0); > if (ptr == (void*)-1) { > perror("[-] mmap failed with MAP_PRIVATE | MAP_ANONYMOUS"); > exit(1); > } > while(1) > sleep(1); > return 0; > } DONTDUMP is available since Linux 3.4. I presume our minimum kernel version is higher than that. I have little idea of how dumping works, but reading the manpage for madvise, DONTDUMP should be the way to go here. Also, reading up on PROT_NONE, i can't find any references to this memory necessarily being excluded from core dumps. That said, I've run the program above, and i got a core dump sized ~100K. Do i need any special configuration to trigger core dump that would include that anonymous memory? -- Thanks, Anatoly ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory 2020-04-21 12:19 ` Burakov, Anatoly @ 2020-04-21 16:38 ` Feng Li 2020-04-21 17:02 ` Burakov, Anatoly 0 siblings, 1 reply; 19+ messages in thread From: Feng Li @ 2020-04-21 16:38 UTC (permalink / raw) To: Burakov, Anatoly; +Cc: David Marchand, Li Feng, Kyle Zhang, dev, fanyang Hi Anatoly, This program could run like this: gcc test_map.c ./a.out 2 & gcore `pidof a.out` You will get a core dump sized to 2GiB. Thanks, Feng Li Burakov, Anatoly <anatoly.burakov@intel.com> 于2020年4月21日周二 下午8:19写道: > > On 21-Apr-20 12:06 PM, Feng Li wrote: > > #include <sys/mman.h> > > #include <time.h> > > #include <stdint.h> > > #include <unistd.h> > > #include <stdlib.h> > > #include <stdio.h> > > > > int main(int argc, char** argv) { > > // FIXME(fengli): XXXXX > > uint64_t gb = atoi(argv[1]); > > void* ptr = mmap(0, gb << 30, PROT_NONE, MAP_PRIVATE | > > MAP_ANONYMOUS, -1, 0); > > if (ptr == (void*)-1) { > > perror("[-] mmap failed with MAP_PRIVATE | MAP_ANONYMOUS"); > > exit(1); > > } > > while(1) > > sleep(1); > > return 0; > > } > > DONTDUMP is available since Linux 3.4. I presume our minimum kernel > version is higher than that. > > I have little idea of how dumping works, but reading the manpage for > madvise, DONTDUMP should be the way to go here. Also, reading up on > PROT_NONE, i can't find any references to this memory necessarily being > excluded from core dumps. > > That said, I've run the program above, and i got a core dump sized > ~100K. Do i need any special configuration to trigger core dump that > would include that anonymous memory? > > -- > Thanks, > Anatoly ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory 2020-04-21 16:38 ` Feng Li @ 2020-04-21 17:02 ` Burakov, Anatoly 2020-04-22 3:13 ` Li Feng 0 siblings, 1 reply; 19+ messages in thread From: Burakov, Anatoly @ 2020-04-21 17:02 UTC (permalink / raw) To: Feng Li; +Cc: David Marchand, Li Feng, Kyle Zhang, dev, fanyang On 21-Apr-20 5:38 PM, Feng Li wrote: > Hi Anatoly, > > This program could run like this: > gcc test_map.c > ./a.out 2 & > gcore `pidof a.out` > > You will get a core dump sized to 2GiB. > > Thanks, > Feng Li > I did just that, and my core dump was ~100K in size. Hence my asking about any special configuration required. -- Thanks, Anatoly ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory 2020-04-21 17:02 ` Burakov, Anatoly @ 2020-04-22 3:13 ` Li Feng 2020-04-22 9:53 ` Burakov, Anatoly 0 siblings, 1 reply; 19+ messages in thread From: Li Feng @ 2020-04-22 3:13 UTC (permalink / raw) To: Burakov, Anatoly; +Cc: Feng Li, David Marchand, Kyle Zhang, dev, Yang Fan Really?So weird. I have tested on 4 machines, running CentOS 7. The core dump size is the same as the first argument GiB. Thanks, Feng Li Burakov, Anatoly <anatoly.burakov@intel.com> 于2020年4月22日周三 上午1:02写道: > > On 21-Apr-20 5:38 PM, Feng Li wrote: > > Hi Anatoly, > > > > This program could run like this: > > gcc test_map.c > > ./a.out 2 & > > gcore `pidof a.out` > > > > You will get a core dump sized to 2GiB. > > > > Thanks, > > Feng Li > > > > I did just that, and my core dump was ~100K in size. Hence my asking > about any special configuration required. > > -- > Thanks, > Anatoly -- The SmartX email address is only for business purpose. Any sent message that is not related to the business is not authorized or permitted by SmartX. 本邮箱为北京志凌海纳科技有限公司(SmartX)工作邮箱. 如本邮箱发出的邮件与工作无关,该邮件未得到本公司任何的明示或默示的授权. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory 2020-04-22 3:13 ` Li Feng @ 2020-04-22 9:53 ` Burakov, Anatoly [not found] ` <CAEK8JBCdfZJiKNjDNgC9nDGLni9Dvw+U1doRFnh+zkAs5TXEsg@mail.gmail.com> 0 siblings, 1 reply; 19+ messages in thread From: Burakov, Anatoly @ 2020-04-22 9:53 UTC (permalink / raw) To: Li Feng; +Cc: Feng Li, David Marchand, Kyle Zhang, dev, Yang Fan On 22-Apr-20 4:13 AM, Li Feng wrote: > Really?So weird. > I have tested on 4 machines, running CentOS 7. > The core dump size is the same as the first argument GiB. > > Thanks, > > Feng Li > > Burakov, Anatoly <anatoly.burakov@intel.com> 于2020年4月22日周三 上午1:02写道: >> >> On 21-Apr-20 5:38 PM, Feng Li wrote: >>> Hi Anatoly, >>> >>> This program could run like this: >>> gcc test_map.c >>> ./a.out 2 & >>> gcore `pidof a.out` >>> >>> You will get a core dump sized to 2GiB. >>> >>> Thanks, >>> Feng Li >>> >> >> I did just that, and my core dump was ~100K in size. Hence my asking >> about any special configuration required. >> >> -- >> Thanks, >> Anatoly > Apologies, i've looked at the wrong core dump file. I do get a 2G core dump out of it. However, i've added madvise call for that memory and run the exact same command line you gave me, and i can see multiple core dump files, some of them are 2G files. Does that mean that MADV_DONTDUMP doesn't work? -- Thanks, Anatoly ^ permalink raw reply [flat|nested] 19+ messages in thread
[parent not found: <CAEK8JBCdfZJiKNjDNgC9nDGLni9Dvw+U1doRFnh+zkAs5TXEsg@mail.gmail.com>]
* Re: [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory [not found] ` <CAEK8JBCdfZJiKNjDNgC9nDGLni9Dvw+U1doRFnh+zkAs5TXEsg@mail.gmail.com> @ 2020-04-23 12:22 ` Burakov, Anatoly 0 siblings, 0 replies; 19+ messages in thread From: Burakov, Anatoly @ 2020-04-23 12:22 UTC (permalink / raw) To: Feng Li; +Cc: Li Feng, David Marchand, Kyle Zhang, dev, Yang Fan On 23-Apr-20 7:36 AM, Feng Li wrote: > Hi, > I have tested as follows, the core dump file is ~ 200KB. > It should generate one core dump file each crash. > > #include <sys/mman.h> > #include <time.h> > #include <stdint.h> > #include <unistd.h> > #include <stdlib.h> > #include <stdio.h> > > int main(int argc, char** argv) { > // FIXME(fengli): XXXXX > uint64_t size = 1<<30; > void* ptr = mmap(0, size , PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); > if (ptr == (void*)-1) { > perror("[-] mmap failed with MAP_PRIVATE | MAP_ANONYMOUS"); > exit(1); > } > if (madvise(ptr, size , MADV_DONTDUMP) != 0) > perror("[-] madvise failed"); > while(1) > sleep(1); > return 0; > } > That's odd, your code works. Mine, even though it did the same thing, didn't work the same way. My compiler must like you more than it likes me :) (or perhaps i had a typo...) Anyway, i can see that this indeed prevents core dumps on madvise'd memory (i've also tested it with PROT_NONE). I'll go ahead and ack the original patch then. -- Thanks, Anatoly ^ permalink raw reply [flat|nested] 19+ messages in thread
* [dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory [not found] <20200420070508.645533-1-fengli@smartx.com> 2020-04-20 7:07 ` [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory Li Feng @ 2020-04-23 15:43 ` Li Feng 2020-04-23 16:33 ` Burakov, Anatoly 1 sibling, 1 reply; 19+ messages in thread From: Li Feng @ 2020-04-23 15:43 UTC (permalink / raw) To: Anatoly Burakov; +Cc: dev, kyle, lifeng1519, fanyang, Li Feng Avoid dump all mapped memory to a core dump file when crash. Otherwise it will very large and it's hard to analyze with gdb. In my test, it will dump 128GiB memory to a core dump file when integrated to spdk with default configuration. Signed-off-by: Li Feng <fengli@smartx.com> --- lib/librte_eal/common/eal_common_memory.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c index cc7d54e0c..2d9564b28 100644 --- a/lib/librte_eal/common/eal_common_memory.c +++ b/lib/librte_eal/common/eal_common_memory.c @@ -177,6 +177,20 @@ eal_get_virtual_area(void *requested_addr, size_t *size, after_len = RTE_PTR_DIFF(map_end, aligned_end); if (after_len > 0) munmap(aligned_end, after_len); + + /* + * Exclude this pages from a core dump. + */ + if (madvise(aligned_addr, *size, MADV_DONTDUMP) != 0) + RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n", + strerror(errno)); + } else { + /* + * Exclude this pages from a core dump. + */ + if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0) + RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n", + strerror(errno)); } return aligned_addr; -- 2.11.0 -- The SmartX email address is only for business purpose. Any sent message that is not related to the business is not authorized or permitted by SmartX. 本邮箱为北京志凌海纳科技有限公司(SmartX)工作邮箱. 如本邮箱发出的邮件与工作无关,该邮件未得到本公司任何的明示或默示的授权. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory 2020-04-23 15:43 ` [dpdk-dev] [PATCH v2] " Li Feng @ 2020-04-23 16:33 ` Burakov, Anatoly 2020-04-23 20:04 ` David Marchand 0 siblings, 1 reply; 19+ messages in thread From: Burakov, Anatoly @ 2020-04-23 16:33 UTC (permalink / raw) To: Li Feng; +Cc: dev, kyle, lifeng1519, fanyang On 23-Apr-20 4:43 PM, Li Feng wrote: > Avoid dump all mapped memory to a core dump file when crash. > Otherwise it will very large and it's hard to analyze with gdb. > > In my test, it will dump 128GiB memory to a core dump file when integrated > to spdk with default configuration. Suggested rewording: Currently, even though memory is mapped with PROT_NONE, this does not cause it to be excluded from core dumps. This is counter-productive, because in a lot of cases, this memory will go unused (e.g. when the memory subsystem preallocates VA space but hasn't yet mapped physical pages into it). Use `madvise()` call with MADV_DONTDUMP parameter to exclude the unmapped memory from being dumped. > > Signed-off-by: Li Feng <fengli@smartx.com> > --- > lib/librte_eal/common/eal_common_memory.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c > index cc7d54e0c..2d9564b28 100644 > --- a/lib/librte_eal/common/eal_common_memory.c > +++ b/lib/librte_eal/common/eal_common_memory.c > @@ -177,6 +177,20 @@ eal_get_virtual_area(void *requested_addr, size_t *size, > after_len = RTE_PTR_DIFF(map_end, aligned_end); > if (after_len > 0) > munmap(aligned_end, after_len); > + > + /* > + * Exclude this pages from a core dump. > + */ > + if (madvise(aligned_addr, *size, MADV_DONTDUMP) != 0) > + RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n", > + strerror(errno)); > + } else { > + /* > + * Exclude this pages from a core dump. > + */ > + if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0) > + RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n", > + strerror(errno)); > } > > return aligned_addr; > For the contents of this patch, Acked-by: Anatoly Burakov <anatoly.burakov@intel.com> However, even though this is good to have, after some more thought, i believe the fix is incomplete, because this is not the only place we're reserving anonymous memory. We're also doing so in `eal_memalloc.c:free_seg()`, so an `madvise()` call should also be added there. @David, now that i think of it, the PROT_NONE patch also was incomplete, as we only set PROT_NONE to memory that's initially reserved, but not when it's unmapped and returned back to the pool of anonymous memory. So, eal_memalloc.c should also remap anonymous memory with PROT_NONE. @Li Feng, would you be so kind as to provide a patch replacing PROT_READ with PROT_NONE in eal_memalloc.c as well? Thank you very much! -- Thanks, Anatoly ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory 2020-04-23 16:33 ` Burakov, Anatoly @ 2020-04-23 20:04 ` David Marchand 2020-04-24 9:12 ` Burakov, Anatoly 0 siblings, 1 reply; 19+ messages in thread From: David Marchand @ 2020-04-23 20:04 UTC (permalink / raw) To: Burakov, Anatoly; +Cc: Li Feng, dev, Kyle Zhang, Feng Li, fanyang On Thu, Apr 23, 2020 at 6:34 PM Burakov, Anatoly <anatoly.burakov@intel.com> wrote: > > diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c > > index cc7d54e0c..2d9564b28 100644 > > --- a/lib/librte_eal/common/eal_common_memory.c > > +++ b/lib/librte_eal/common/eal_common_memory.c > > @@ -177,6 +177,20 @@ eal_get_virtual_area(void *requested_addr, size_t *size, > > after_len = RTE_PTR_DIFF(map_end, aligned_end); > > if (after_len > 0) > > munmap(aligned_end, after_len); > > + > > + /* > > + * Exclude this pages from a core dump. > > + */ > > + if (madvise(aligned_addr, *size, MADV_DONTDUMP) != 0) > > + RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n", > > + strerror(errno));> + } else { > > + /* > > + * Exclude this pages from a core dump. > > + */ > > + if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0) > > + RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n", > > + strerror(errno)); > > } > > > > return aligned_addr; > > > > For the contents of this patch, MADV_DONTDUMP does not seem POSIX, but as I said [1], there seems to be a MADV_NOCORE option on FreeBSD. 1: http://inbox.dpdk.org/dev/CAJFAV8y9YtT-7njUz+mD6U8+3XUqYrgp28KD7jy2923EpAcXrg@mail.gmail.com/ > > Acked-by: Anatoly Burakov <anatoly.burakov@intel.com> > > However, even though this is good to have, after some more thought, i > believe the fix is incomplete, because this is not the only place we're > reserving anonymous memory. We're also doing so in > `eal_memalloc.c:free_seg()`, so an `madvise()` call should also be added > there. > > @David, now that i think of it, the PROT_NONE patch also was incomplete, > as we only set PROT_NONE to memory that's initially reserved, but not > when it's unmapped and returned back to the pool of anonymous memory. > So, eal_memalloc.c should also remap anonymous memory with PROT_NONE. I can't disagree if you say so :-). > > @Li Feng, would you be so kind as to provide a patch replacing PROT_READ > with PROT_NONE in eal_memalloc.c as well? Thank you very much! > Once we have the proper fixes, I'd like to get this Cc: stable@dpdk.org. Thanks. -- David Marchand ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory 2020-04-23 20:04 ` David Marchand @ 2020-04-24 9:12 ` Burakov, Anatoly 2020-04-24 9:14 ` Bruce Richardson 0 siblings, 1 reply; 19+ messages in thread From: Burakov, Anatoly @ 2020-04-24 9:12 UTC (permalink / raw) To: David Marchand; +Cc: Li Feng, dev, Kyle Zhang, Feng Li, fanyang On 23-Apr-20 9:04 PM, David Marchand wrote: > On Thu, Apr 23, 2020 at 6:34 PM Burakov, Anatoly > <anatoly.burakov@intel.com> wrote: >>> diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c >>> index cc7d54e0c..2d9564b28 100644 >>> --- a/lib/librte_eal/common/eal_common_memory.c >>> +++ b/lib/librte_eal/common/eal_common_memory.c >>> @@ -177,6 +177,20 @@ eal_get_virtual_area(void *requested_addr, size_t *size, >>> after_len = RTE_PTR_DIFF(map_end, aligned_end); >>> if (after_len > 0) >>> munmap(aligned_end, after_len); >>> + >>> + /* >>> + * Exclude this pages from a core dump. >>> + */ >>> + if (madvise(aligned_addr, *size, MADV_DONTDUMP) != 0) >>> + RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n", >>> + strerror(errno));> + } else { >>> + /* >>> + * Exclude this pages from a core dump. >>> + */ >>> + if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0) >>> + RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n", >>> + strerror(errno)); >>> } >>> >>> return aligned_addr; >>> >> >> For the contents of this patch, > > MADV_DONTDUMP does not seem POSIX, but as I said [1], there seems to > be a MADV_NOCORE option on FreeBSD. > 1: http://inbox.dpdk.org/dev/CAJFAV8y9YtT-7njUz+mD6U8+3XUqYrgp28KD7jy2923EpAcXrg@mail.gmail.com/ > > Oh, right, so this would probably not compile on FreeBSD. Perhaps this function would have to be OS-specific after all (or call into an OS-specific madvise() after reserving the memory area). >> >> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com> >> >> However, even though this is good to have, after some more thought, i >> believe the fix is incomplete, because this is not the only place we're >> reserving anonymous memory. We're also doing so in >> `eal_memalloc.c:free_seg()`, so an `madvise()` call should also be added >> there. >> >> @David, now that i think of it, the PROT_NONE patch also was incomplete, >> as we only set PROT_NONE to memory that's initially reserved, but not >> when it's unmapped and returned back to the pool of anonymous memory. >> So, eal_memalloc.c should also remap anonymous memory with PROT_NONE. > > I can't disagree if you say so :-). Nice to have that kind of power! *evil laugh* > >> >> @Li Feng, would you be so kind as to provide a patch replacing PROT_READ >> with PROT_NONE in eal_memalloc.c as well? Thank you very much! >> > > Once we have the proper fixes, I'd like to get this Cc: stable@dpdk.org. > Thanks. > > -- Thanks, Anatoly ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory 2020-04-24 9:12 ` Burakov, Anatoly @ 2020-04-24 9:14 ` Bruce Richardson 2020-04-24 9:33 ` Feng Li 0 siblings, 1 reply; 19+ messages in thread From: Bruce Richardson @ 2020-04-24 9:14 UTC (permalink / raw) To: Burakov, Anatoly Cc: David Marchand, Li Feng, dev, Kyle Zhang, Feng Li, fanyang On Fri, Apr 24, 2020 at 10:12:10AM +0100, Burakov, Anatoly wrote: > On 23-Apr-20 9:04 PM, David Marchand wrote: > > On Thu, Apr 23, 2020 at 6:34 PM Burakov, Anatoly > > <anatoly.burakov@intel.com> wrote: > > > > diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c > > > > index cc7d54e0c..2d9564b28 100644 > > > > --- a/lib/librte_eal/common/eal_common_memory.c > > > > +++ b/lib/librte_eal/common/eal_common_memory.c > > > > @@ -177,6 +177,20 @@ eal_get_virtual_area(void *requested_addr, size_t *size, > > > > after_len = RTE_PTR_DIFF(map_end, aligned_end); > > > > if (after_len > 0) > > > > munmap(aligned_end, after_len); > > > > + > > > > + /* > > > > + * Exclude this pages from a core dump. > > > > + */ > > > > + if (madvise(aligned_addr, *size, MADV_DONTDUMP) != 0) > > > > + RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n", > > > > + strerror(errno));> + } else { > > > > + /* > > > > + * Exclude this pages from a core dump. > > > > + */ > > > > + if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0) > > > > + RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n", > > > > + strerror(errno)); > > > > } > > > > > > > > return aligned_addr; > > > > > > > > > > For the contents of this patch, > > > > MADV_DONTDUMP does not seem POSIX, but as I said [1], there seems to > > be a MADV_NOCORE option on FreeBSD. > > 1: http://inbox.dpdk.org/dev/CAJFAV8y9YtT-7njUz+mD6U8+3XUqYrgp28KD7jy2923EpAcXrg@mail.gmail.com/ > > > > > > Oh, right, so this would probably not compile on FreeBSD. Perhaps this > function would have to be OS-specific after all (or call into an OS-specific > madvise() after reserving the memory area). > Is it just a differently named flag? If so, I think a single #ifdef macro won't kill us in the common code. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory 2020-04-24 9:14 ` Bruce Richardson @ 2020-04-24 9:33 ` Feng Li 2020-04-24 11:00 ` Burakov, Anatoly 0 siblings, 1 reply; 19+ messages in thread From: Feng Li @ 2020-04-24 9:33 UTC (permalink / raw) To: Bruce Richardson Cc: Burakov, Anatoly, David Marchand, Li Feng, dev, Kyle Zhang, Yang Fan Bruce Richardson <bruce.richardson@intel.com> 于2020年4月24日周五 下午5:14写道: > > On Fri, Apr 24, 2020 at 10:12:10AM +0100, Burakov, Anatoly wrote: > > On 23-Apr-20 9:04 PM, David Marchand wrote: > > > On Thu, Apr 23, 2020 at 6:34 PM Burakov, Anatoly > > > <anatoly.burakov@intel.com> wrote: > > > > > diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c > > > > > index cc7d54e0c..2d9564b28 100644 > > > > > --- a/lib/librte_eal/common/eal_common_memory.c > > > > > +++ b/lib/librte_eal/common/eal_common_memory.c > > > > > @@ -177,6 +177,20 @@ eal_get_virtual_area(void *requested_addr, size_t *size, > > > > > after_len = RTE_PTR_DIFF(map_end, aligned_end); > > > > > if (after_len > 0) > > > > > munmap(aligned_end, after_len); > > > > > + > > > > > + /* > > > > > + * Exclude this pages from a core dump. > > > > > + */ > > > > > + if (madvise(aligned_addr, *size, MADV_DONTDUMP) != 0) > > > > > + RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n", > > > > > + strerror(errno));> + } else { > > > > > + /* > > > > > + * Exclude this pages from a core dump. > > > > > + */ > > > > > + if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0) > > > > > + RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n", > > > > > + strerror(errno)); > > > > > } > > > > > > > > > > return aligned_addr; > > > > > > > > > > > > > For the contents of this patch, > > > > > > MADV_DONTDUMP does not seem POSIX, but as I said [1], there seems to > > > be a MADV_NOCORE option on FreeBSD. > > > 1: http://inbox.dpdk.org/dev/CAJFAV8y9YtT-7njUz+mD6U8+3XUqYrgp28KD7jy2923EpAcXrg@mail.gmail.com/ > > > > > > > > > > Oh, right, so this would probably not compile on FreeBSD. Perhaps this > > function would have to be OS-specific after all (or call into an OS-specific > > madvise() after reserving the memory area). > > > > Is it just a differently named flag? If so, I think a single #ifdef macro > won't kill us in the common code. > Just the flag name is different. I should use RTE_EXEC_ENV_FREEBSD and RTE_EXEC_ENV_LINUX, right? Another question, in `eal_memalloc.c:alloc_seg`, I should undo the DONTMAP of the memory region. Right? @Anatoly Just few minutes, I have prepared a patch for the OS-specific code: --- a/lib/librte_eal/common/eal_private.h +++ b/lib/librte_eal/common/eal_private.h @@ -443,4 +443,20 @@ rte_option_usage(void); uint64_t eal_get_baseaddr(void); +/** + * @internal + * Exclude this pages from a core dump. + * + * @param addr + * The memory region starts. + * + * @param len + * The memory region length.. + * + * @return + * returns 0 or -errno + */ +int +eal_madvise_dontdump(void* addr, size_t len); + #endif /* _EAL_PRIVATE_H_ */ diff --git a/lib/librte_eal/freebsd/eal_memory.c b/lib/librte_eal/freebsd/eal_memory.c index a97d8f0f0..585042dde 100644 --- a/lib/librte_eal/freebsd/eal_memory.c +++ b/lib/librte_eal/freebsd/eal_memory.c @@ -534,3 +534,9 @@ rte_eal_memseg_init(void) memseg_primary_init() : memseg_secondary_init(); } + +int +eal_madvise_dontdump(void* addr, size_t len) +{ + return madvise(addr, len, MADV_NOCORE); +} diff --git a/lib/librte_eal/linux/eal_memory.c b/lib/librte_eal/linux/eal_memory.c index 7a9c97ff8..cfdbfccfe 100644 --- a/lib/librte_eal/linux/eal_memory.c +++ b/lib/librte_eal/linux/eal_memory.c @@ -2479,3 +2479,9 @@ rte_eal_memseg_init(void) #endif memseg_secondary_init(); } + +int +eal_madvise_dontdump(void* addr, size_t len) +{ + return madvise(addr, len, MADV_DONTDUMP); +} ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory 2020-04-24 9:33 ` Feng Li @ 2020-04-24 11:00 ` Burakov, Anatoly 2020-04-24 12:03 ` Li Feng 0 siblings, 1 reply; 19+ messages in thread From: Burakov, Anatoly @ 2020-04-24 11:00 UTC (permalink / raw) To: Feng Li, Bruce Richardson Cc: David Marchand, Li Feng, dev, Kyle Zhang, Yang Fan On 24-Apr-20 10:33 AM, Feng Li wrote: > Bruce Richardson <bruce.richardson@intel.com> 于2020年4月24日周五 下午5:14写道: >> >> On Fri, Apr 24, 2020 at 10:12:10AM +0100, Burakov, Anatoly wrote: >>> On 23-Apr-20 9:04 PM, David Marchand wrote: >>>> On Thu, Apr 23, 2020 at 6:34 PM Burakov, Anatoly >>>> <anatoly.burakov@intel.com> wrote: >>>>>> diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c >>>>>> index cc7d54e0c..2d9564b28 100644 >>>>>> --- a/lib/librte_eal/common/eal_common_memory.c >>>>>> +++ b/lib/librte_eal/common/eal_common_memory.c >>>>>> @@ -177,6 +177,20 @@ eal_get_virtual_area(void *requested_addr, size_t *size, >>>>>> after_len = RTE_PTR_DIFF(map_end, aligned_end); >>>>>> if (after_len > 0) >>>>>> munmap(aligned_end, after_len); >>>>>> + >>>>>> + /* >>>>>> + * Exclude this pages from a core dump. >>>>>> + */ >>>>>> + if (madvise(aligned_addr, *size, MADV_DONTDUMP) != 0) >>>>>> + RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n", >>>>>> + strerror(errno));> + } else { >>>>>> + /* >>>>>> + * Exclude this pages from a core dump. >>>>>> + */ >>>>>> + if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0) >>>>>> + RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n", >>>>>> + strerror(errno)); >>>>>> } >>>>>> >>>>>> return aligned_addr; >>>>>> >>>>> >>>>> For the contents of this patch, >>>> >>>> MADV_DONTDUMP does not seem POSIX, but as I said [1], there seems to >>>> be a MADV_NOCORE option on FreeBSD. >>>> 1: http://inbox.dpdk.org/dev/CAJFAV8y9YtT-7njUz+mD6U8+3XUqYrgp28KD7jy2923EpAcXrg@mail.gmail.com/ >>>> >>>> >>> >>> Oh, right, so this would probably not compile on FreeBSD. Perhaps this >>> function would have to be OS-specific after all (or call into an OS-specific >>> madvise() after reserving the memory area). >>> >> >> Is it just a differently named flag? If so, I think a single #ifdef macro >> won't kill us in the common code. >> > Just the flag name is different. > I should use RTE_EXEC_ENV_FREEBSD and RTE_EXEC_ENV_LINUX, right? Yes, but we need this in two places, so a function call is still necessary. > > Another question, in `eal_memalloc.c:alloc_seg`, I should undo the > DONTMAP of the memory region. > Right? @Anatoly I don't think it's necessary. When you map different memory into that region, madvise() flags no longer apply. To be sure, i just tested this by adding another mmap() call after madvise() (in your test app) and remapping the same memory with MAP_FIXED, and the core dump was back to 1GB of size. So, no, i don't think you should undo anything - the system does so automatically. > > Just few minutes, I have prepared a patch for the OS-specific code: > --- a/lib/librte_eal/common/eal_private.h > +++ b/lib/librte_eal/common/eal_private.h > @@ -443,4 +443,20 @@ rte_option_usage(void); > uint64_t > eal_get_baseaddr(void); > > +/** > + * @internal > + * Exclude this pages from a core dump. > + * > + * @param addr > + * The memory region starts. > + * > + * @param len > + * The memory region length.. > + * > + * @return > + * returns 0 or -errno > + */ > +int > +eal_madvise_dontdump(void* addr, size_t len); > + > #endif /* _EAL_PRIVATE_H_ */ > diff --git a/lib/librte_eal/freebsd/eal_memory.c > b/lib/librte_eal/freebsd/eal_memory.c > index a97d8f0f0..585042dde 100644 > --- a/lib/librte_eal/freebsd/eal_memory.c > +++ b/lib/librte_eal/freebsd/eal_memory.c > @@ -534,3 +534,9 @@ rte_eal_memseg_init(void) > memseg_primary_init() : > memseg_secondary_init(); > } > + > +int > +eal_madvise_dontdump(void* addr, size_t len) > +{ > + return madvise(addr, len, MADV_NOCORE); > +} > diff --git a/lib/librte_eal/linux/eal_memory.c > b/lib/librte_eal/linux/eal_memory.c > index 7a9c97ff8..cfdbfccfe 100644 > --- a/lib/librte_eal/linux/eal_memory.c > +++ b/lib/librte_eal/linux/eal_memory.c > @@ -2479,3 +2479,9 @@ rte_eal_memseg_init(void) > #endif > memseg_secondary_init(); > } > + > +int > +eal_madvise_dontdump(void* addr, size_t len) > +{ > + return madvise(addr, len, MADV_DONTDUMP); > +} > That would work as well (with added FreeBSD code of course), however if everyone else is OK with it, i'll settle for an #ifdef in common code. -- Thanks, Anatoly ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [dpdk-dev] [PATCH v2] eal: add madvise to avoid dump memory 2020-04-24 11:00 ` Burakov, Anatoly @ 2020-04-24 12:03 ` Li Feng 0 siblings, 0 replies; 19+ messages in thread From: Li Feng @ 2020-04-24 12:03 UTC (permalink / raw) To: Burakov, Anatoly Cc: Feng Li, Bruce Richardson, David Marchand, dev, Kyle Zhang, Yang Fan Thanks, Feng Li Burakov, Anatoly <anatoly.burakov@intel.com> 于2020年4月24日周五 下午7:00写道: > > On 24-Apr-20 10:33 AM, Feng Li wrote: > > Bruce Richardson <bruce.richardson@intel.com> 于2020年4月24日周五 下午5:14写道: > >> > >> On Fri, Apr 24, 2020 at 10:12:10AM +0100, Burakov, Anatoly wrote: > >>> On 23-Apr-20 9:04 PM, David Marchand wrote: > >>>> On Thu, Apr 23, 2020 at 6:34 PM Burakov, Anatoly > >>>> <anatoly.burakov@intel.com> wrote: > >>>>>> diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c > >>>>>> index cc7d54e0c..2d9564b28 100644 > >>>>>> --- a/lib/librte_eal/common/eal_common_memory.c > >>>>>> +++ b/lib/librte_eal/common/eal_common_memory.c > >>>>>> @@ -177,6 +177,20 @@ eal_get_virtual_area(void *requested_addr, size_t *size, > >>>>>> after_len = RTE_PTR_DIFF(map_end, aligned_end); > >>>>>> if (after_len > 0) > >>>>>> munmap(aligned_end, after_len); > >>>>>> + > >>>>>> + /* > >>>>>> + * Exclude this pages from a core dump. > >>>>>> + */ > >>>>>> + if (madvise(aligned_addr, *size, MADV_DONTDUMP) != 0) > >>>>>> + RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n", > >>>>>> + strerror(errno));> + } else { > >>>>>> + /* > >>>>>> + * Exclude this pages from a core dump. > >>>>>> + */ > >>>>>> + if (madvise(mapped_addr, map_sz, MADV_DONTDUMP) != 0) > >>>>>> + RTE_LOG(WARNING, EAL, "Madvise with MADV_DONTDUMP failed: %s\n", > >>>>>> + strerror(errno)); > >>>>>> } > >>>>>> > >>>>>> return aligned_addr; > >>>>>> > >>>>> > >>>>> For the contents of this patch, > >>>> > >>>> MADV_DONTDUMP does not seem POSIX, but as I said [1], there seems to > >>>> be a MADV_NOCORE option on FreeBSD. > >>>> 1: http://inbox.dpdk.org/dev/CAJFAV8y9YtT-7njUz+mD6U8+3XUqYrgp28KD7jy2923EpAcXrg@mail.gmail.com/ > >>>> > >>>> > >>> > >>> Oh, right, so this would probably not compile on FreeBSD. Perhaps this > >>> function would have to be OS-specific after all (or call into an OS-specific > >>> madvise() after reserving the memory area). > >>> > >> > >> Is it just a differently named flag? If so, I think a single #ifdef macro > >> won't kill us in the common code. > >> > > Just the flag name is different. > > I should use RTE_EXEC_ENV_FREEBSD and RTE_EXEC_ENV_LINUX, right? > > Yes, but we need this in two places, so a function call is still necessary. > > > > > Another question, in `eal_memalloc.c:alloc_seg`, I should undo the > > DONTMAP of the memory region. > > Right? @Anatoly > > I don't think it's necessary. When you map different memory into that > region, madvise() flags no longer apply. To be sure, i just tested this > by adding another mmap() call after madvise() (in your test app) and > remapping the same memory with MAP_FIXED, and the core dump was back to > 1GB of size. So, no, i don't think you should undo anything - the system > does so automatically. Got it. > > > > > Just few minutes, I have prepared a patch for the OS-specific code: > > --- a/lib/librte_eal/common/eal_private.h > > +++ b/lib/librte_eal/common/eal_private.h > > @@ -443,4 +443,20 @@ rte_option_usage(void); > > uint64_t > > eal_get_baseaddr(void); > > > > +/** > > + * @internal > > + * Exclude this pages from a core dump. > > + * > > + * @param addr > > + * The memory region starts. > > + * > > + * @param len > > + * The memory region length.. > > + * > > + * @return > > + * returns 0 or -errno > > + */ > > +int > > +eal_madvise_dontdump(void* addr, size_t len); > > + > > #endif /* _EAL_PRIVATE_H_ */ > > diff --git a/lib/librte_eal/freebsd/eal_memory.c > > b/lib/librte_eal/freebsd/eal_memory.c > > index a97d8f0f0..585042dde 100644 > > --- a/lib/librte_eal/freebsd/eal_memory.c > > +++ b/lib/librte_eal/freebsd/eal_memory.c > > @@ -534,3 +534,9 @@ rte_eal_memseg_init(void) > > memseg_primary_init() : > > memseg_secondary_init(); > > } > > + > > +int > > +eal_madvise_dontdump(void* addr, size_t len) > > +{ > > + return madvise(addr, len, MADV_NOCORE); > > +} > > diff --git a/lib/librte_eal/linux/eal_memory.c > > b/lib/librte_eal/linux/eal_memory.c > > index 7a9c97ff8..cfdbfccfe 100644 > > --- a/lib/librte_eal/linux/eal_memory.c > > +++ b/lib/librte_eal/linux/eal_memory.c > > @@ -2479,3 +2479,9 @@ rte_eal_memseg_init(void) > > #endif > > memseg_secondary_init(); > > } > > + > > +int > > +eal_madvise_dontdump(void* addr, size_t len) > > +{ > > + return madvise(addr, len, MADV_DONTDUMP); > > +} > > > > That would work as well (with added FreeBSD code of course), however if > everyone else is OK with it, i'll settle for an #ifdef in common code. > > -- > Thanks, > Anatoly -- The SmartX email address is only for business purpose. Any sent message that is not related to the business is not authorized or permitted by SmartX. 本邮箱为北京志凌海纳科技有限公司(SmartX)工作邮箱. 如本邮箱发出的邮件与工作无关,该邮件未得到本公司任何的明示或默示的授权. ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2020-04-26 20:29 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20200420070508.645533-1-fengli@smartx.com> 2020-04-20 7:07 ` [dpdk-dev] [PATCH] eal: add madvise to avoid dump memory Li Feng 2020-04-20 7:13 ` David Marchand 2020-04-20 9:40 ` Feng Li 2020-04-21 7:41 ` David Marchand 2020-04-21 11:06 ` Feng Li 2020-04-21 12:19 ` Burakov, Anatoly 2020-04-21 16:38 ` Feng Li 2020-04-21 17:02 ` Burakov, Anatoly 2020-04-22 3:13 ` Li Feng 2020-04-22 9:53 ` Burakov, Anatoly [not found] ` <CAEK8JBCdfZJiKNjDNgC9nDGLni9Dvw+U1doRFnh+zkAs5TXEsg@mail.gmail.com> 2020-04-23 12:22 ` Burakov, Anatoly 2020-04-23 15:43 ` [dpdk-dev] [PATCH v2] " Li Feng 2020-04-23 16:33 ` Burakov, Anatoly 2020-04-23 20:04 ` David Marchand 2020-04-24 9:12 ` Burakov, Anatoly 2020-04-24 9:14 ` Bruce Richardson 2020-04-24 9:33 ` Feng Li 2020-04-24 11:00 ` Burakov, Anatoly 2020-04-24 12:03 ` Li Feng
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).