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 to stress the
> > codepath.)
>
>
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 the
>> codepath.)
>
> Looks ok to me. Doing a profile (without th
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()" might be
> > interesting
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 RCU freeing, obviously) gives me
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 want to populate all the
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 notable
> > performance imp
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 unconditional if it doesn't reall
On x86 software page-table walkers depend on the fact that remote TLB flush
does an IPI: walk is performed lockless but with interrupts disabled and in
case the pagetable is freed the freeing CPU will get blocked as remote TLB
flush is required. On other architecture which don't require an IPI to d