On Wed, Aug 23, 2017 at 04:03:53PM -0700, Linus Torvalds wrote:
> On Wed, Aug 23, 2017 at 3:36 PM, Kirill A. Shutemov
> wrote:
> >
> > Below is test cases that allocates a lot of page tables and measuare
> > fork/exit time. (I'm not entirely sure it's the best way
Linus Torvalds writes:
> On Wed, Aug 23, 2017 at 3:36 PM, Kirill A. Shutemov
> wrote:
>>
>> Below is test cases that allocates a lot of page tables and measuare
>> fork/exit time. (I'm not entirely sure it's the best way to stress
On Wed, Aug 23, 2017 at 08:27:18PM +, Linus Torvalds wrote:
> On Wed, Aug 23, 2017 at 12:59 PM, Kirill A. Shutemov
> wrote:
> >
> > In this case we need performance numbers for !PARAVIRT kernel.
>
> Yes.
>
> > Numbers for tight loop of "mmap(MAP_POPULATE); munmap()"
On Wed, Aug 23, 2017 at 3:36 PM, Kirill A. Shutemov
wrote:
>
> Below is test cases that allocates a lot of page tables and measuare
> fork/exit time. (I'm not entirely sure it's the best way to stress the
> codepath.)
Looks ok to me. Doing a profile (without the
On Wed, Aug 23, 2017 at 12:59 PM, Kirill A. Shutemov
wrote:
>
> In this case we need performance numbers for !PARAVIRT kernel.
Yes.
> Numbers for tight loop of "mmap(MAP_POPULATE); munmap()" might be
> interesting too for worst case scenario.
Actually, I don't think you
On Wed, Aug 23, 2017 at 11:26:46AM -0700, Linus Torvalds wrote:
> On Wed, Aug 23, 2017 at 6:45 AM, Vitaly Kuznetsov wrote:
> >
> > Solve the issue by enabling RCU-based table free mechanism when PARAVIRT
> > is selected in config. Testing with kernbench doesn't show any
On Wed, Aug 23, 2017 at 6:45 AM, Vitaly Kuznetsov wrote:
>
> Solve the issue by enabling RCU-based table free mechanism when PARAVIRT
> is selected in config. Testing with kernbench doesn't show any notable
> performance impact:
I wonder if we should just make it