On Tue, Oct 12, 2021 at 11:09 PM Dmitry Kozlyuk <dkozl...@nvidia.com> wrote: > > From this, I see two parts in this patch: > > - faster restart, reusing hugepage files as is (combination of not calling > > unlink() and doing "clear on alloc"), > > This part is interesting, and I think a single knob for this would be > > enough. > > In combination with rte_extmem* API this know would indeed allow to implement > the feature in the app. However, the drawback is that all the logic to select > hugepage size, NUMA, and names would need to be done from the app, probably > with its own options. OTOH, there is already hugetlbfs and numactl to avoid > apps duplicating this logic. Also, it's not only the fast restart, but also > the fast initial start on a prepared system.
How do you "prepare" a system? > > > - 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? Thanks. -- David Marchand
