Thanks for your explanation. Will try in memory mode.;) Burakov, Anatoly <anatoly.bura...@intel.com>于2021年9月29日 周三下午8:40写道：
> > -----Original Message----- > > From: Thomas Monjalon <tho...@monjalon.net> > > Sent: Wednesday, September 29, 2021 12:11 PM > > To: Jiany Wu <wujianyue...@gmail.com>; Burakov, Anatoly > > <anatoly.bura...@intel.com> > > Cc: users@dpdk.org; Richardson, Bruce <bruce.richard...@intel.com>; > > olivier.m...@6wind.com; dmitry.kozl...@gmail.com; > > step...@networkplumber.org; Mcnamara, John > > <john.mcnam...@intel.com> > > Subject: Re: [dpdk-users] can we reserve hugepage and not release > > > > 29/09/2021 12:16, Burakov, Anatoly: > > > From: Thomas Monjalon <tho...@monjalon.net> > > > > 18/09/2021 04:37, Jiany Wu: > > > > > Hello, > > > > > > > > > > I met a scenario that, need to start and stop the container many > > > > > times for the hugepage. But after several times container start > > > > > and stop, the hugepage is not able to reserve. > > > > > Hugepage size is 2MB, and HW only support 2MB, can't support 1GB. > > > > > Is there anyway to make sure the hugepage is still kept continuous? > > > > > Thanks indeed. > > > > > > > > Interesting question. > > > > I think we need to address it in the DPDK documentation. > > > > > > > > Anatoly, Stephen, Bruce, any advice please? > > > > > > > > > > Hi, > > > > > > From description, I don't quite understand what's the issue here. Is > the > > problem about "contiguousness of memory", or is it about inability to > reserve > > more hugepages? > > > > I think the issue is that sometimes some pages are not properly > released, so > > we cannot reserve them again. > > That's something I experienced myself. > > Any trick to reset hugepages state? > > [[AB]] > Under normal circumstances, the hugepage files would just be deleted and > recreated the next time a primary process initializes even if there are > leftover pages. > > That said, assuming the pages are not "released" because DPDK has left a > few files behind and a new container doesn't have permissions to delete > them (or can't for some other reason), then there is very little DPDK can > do other than track down all memory leaks. For example, using RX callback > feature is intentionally causing a memory leak because by default the API > will not free the callback structure as we cannot guarantee that there are > no Dataplane threads still using that structure. Individual > drivers/libraries might also leak memory due to e.g. secondary process > usage. For example, in the general case, if something is meant to be shared > by primary and secondary, but primary cannot free() it because it might > still be used by secondaries, and secondaries have no way of verifying > whether the resource is being used by other processes, or can be freed. > > Put it simply, sometimes DPDK may leak memory either out of necessity, or > even intentionally, to avoid potential use-after-free errors, and there's > no general way to solve this problem that I'm aware of. This is the kind of > stuff --in-memory mode was introduced to address, as when hugepages are in > memory, there can never be leaks because we never touch the filesystem in > the first place, so if there is a recommended way to address this at all, > it would be --in-memory mode. > > > > > > How are hugepages assigned to your container? > > > Have you tried using --in-memory mode? > > > > > >
