On Mon, Nov 8, 2021 at 3:27 PM Dmitry Kozlyuk <dkozl...@nvidia.com> wrote: > > Hi David, > > > -----Original Message----- > > From: David Marchand <david.march...@redhat.com> > [...] > > > > - finegrained control of hugepage files, but it has the drawback of > > > > imposing primary/secondary run with the same options. > > > > The second part seems complex to configure. I see conflicts with > > > > existing options, so it seems a good way to get caught up in the > > > > carpet (sorry if it translates badly from French :p). > > > > > > I don't see why synchronizing memory options is a big issue. > > > > We have too many options for the memory subsystem. > > > > I mentionned --socket-mem, --huge-dir, --file-prefix. > > But there is also --huge-unlink, --no-shconf, --in-memory, --legacy-mem, - > > -single-file-segments, --match-allocations and --socket-limit. > > Some of those do part of the job, others are incompatible with this new > > option and probably some are orthogonal. > > > > Sure we can add a new one that prepare your toasts, coffee and wake up the > > kids (that's progress!). > > > > Maybe you can provide an example on how this is used? > > Sorry for the late reply.
No problem. > > After more consideration offline with Thomas > we concluded that the --mem-file option is indeed too intrusive. > I'm going to propose a new solution for the slow restart issue for 22.02, > probably with a knob like you proposed, > only not just changing when the memory is zeroed, > but most importantly allowing EAL to reuse hugepages. > So that in the end the usage would be as follows, > and if it's a restart, memory clearing would be bypassed: > > ./dpdk-app --huge-reuse -- ... > > Refactoring and benchmark patches may still be useful, > so review efforts were hopefully not in vain. > Thank you for asking the right questions! > > FWIW, I agree that memory options should be cleaned up independently. Looking forward to 22.02 :-). Thanks Dmitry. -- David Marchand
