On Tue, Mar 10, 2020 at 4:08 PM Ferruh Yigit wrote:
> >> +1 to the idea, testpmd initialization was taking too lock without
> >> '--no-mlockall', but this code looks complex for the application level.
> >>
> >> We can do this for testpmd but does all applications need to do something
> >> similar?
On 3/10/2020 2:55 PM, David Marchand wrote:
> On Tue, Mar 10, 2020 at 3:49 PM Ferruh Yigit wrote:
>>
>> On 3/6/2020 2:48 PM, David Marchand wrote:
>>> Since 18.05 and the memory subsystem rework, EAL reserves some big
>>> (unused) mappings.
>>>
>>> In testpmd, we have been locking all pages to avo
On Tue, Mar 10, 2020 at 3:49 PM Ferruh Yigit wrote:
>
> On 3/6/2020 2:48 PM, David Marchand wrote:
> > Since 18.05 and the memory subsystem rework, EAL reserves some big
> > (unused) mappings.
> >
> > In testpmd, we have been locking all pages to avoid page faults during
> > benchmark/performance
On 3/6/2020 2:48 PM, David Marchand wrote:
> Since 18.05 and the memory subsystem rework, EAL reserves some big
> (unused) mappings.
>
> In testpmd, we have been locking all pages to avoid page faults during
> benchmark/performance regression tests [1].
> However, asking for locking all the pages
Since 18.05 and the memory subsystem rework, EAL reserves some big
(unused) mappings.
In testpmd, we have been locking all pages to avoid page faults during
benchmark/performance regression tests [1].
However, asking for locking all the pages triggers issues on FreeBSD [2]
and becomes really heavy
5 matches
Mail list logo
