On Tue, Aug 27, 2019 at 01:04:18PM +0100, Burakov, Anatoly wrote:
> On 26-Aug-19 2:44 PM, Jim Harris wrote:
> > Ideally, get_tsc_freq_arch() is able to provide the
> > TSC rate using arch-specific means. When that is not
> > possible, DPDK reverts to calculating the TSC rate with
> > a 100ms nanosleep or 1s sleep. The latter occurs more
> > frequently in VMs which often do not have access to the
> > data they need from arch-specific means (CPUID leaf 0x15
> > or MSR 0xCE on x86).
> >
> > In secondary processes, the extra 100ms is especially
> > noticeable and consumes the bulk of rte_eal_init()
> > execution time. To resolve this extra delay, have
> > the primary process put the TSC rate into a shared
> > memory region that the secondary process can lookup.
> >
> > Reduces rte_eal_init() execution time in a secondary
> > process from 165ms to 66ms on my test system.
> >
> > Signed-off-by: Jim Harris <james.r.har...@intel.com>
> > ---
>
> I think this is a bad idea. If you're allocating something, you're supposed
> to free it in rte_eal_cleanup(). If you don't, that memory leaks (i.e. there
> are leftover hugepages after process exit). Since both primary and secondary
> are referencing it (even if only at init), there is no safe way to free this
> memzone.
>
What is the issue with not freeing it? How do we handle this for other
global data to be shared?
