Re: [PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork

2019-10-05 Thread Wei Yang
On Fri, Oct 04, 2019 at 06:15:54PM -0700, Matthew Wilcox wrote: >On Sat, Oct 05, 2019 at 07:48:45AM +0800, Wei Yang wrote: >> On Fri, Oct 04, 2019 at 09:11:20AM -0700, Matthew Wilcox wrote: >> >On Sat, Oct 05, 2019 at 12:06:32AM +0800, Wei Yang wrote: >> >> After this change, kernel build test

Re: [PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork

2019-10-04 Thread Matthew Wilcox
On Sat, Oct 05, 2019 at 07:48:45AM +0800, Wei Yang wrote: > On Fri, Oct 04, 2019 at 09:11:20AM -0700, Matthew Wilcox wrote: > >On Sat, Oct 05, 2019 at 12:06:32AM +0800, Wei Yang wrote: > >> After this change, kernel build test reduces 20% anon_vma allocation. > > > >But does it have any effect on

Re: [PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork

2019-10-04 Thread Wei Yang
On Fri, Oct 04, 2019 at 07:45:26PM -0400, Rik van Riel wrote: >On Sat, 2019-10-05 at 00:06 +0800, Wei Yang wrote: >> In function __anon_vma_prepare(), we will try to find anon_vma if it >> is >> possible to reuse it. While on fork, the logic is different. >> >> Since commit 5beb49305251 ("mm:

Re: [PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork

2019-10-04 Thread Wei Yang
On Fri, Oct 04, 2019 at 09:11:20AM -0700, Matthew Wilcox wrote: >On Sat, Oct 05, 2019 at 12:06:32AM +0800, Wei Yang wrote: >> After this change, kernel build test reduces 20% anon_vma allocation. > >But does it have any effect on elapsed time or peak memory consumption? Do the same kernel build

Re: [PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork

2019-10-04 Thread Rik van Riel
On Sat, 2019-10-05 at 00:06 +0800, Wei Yang wrote: > In function __anon_vma_prepare(), we will try to find anon_vma if it > is > possible to reuse it. While on fork, the logic is different. > > Since commit 5beb49305251 ("mm: change anon_vma linking to fix > multi-process server scalability

Re: [PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork

2019-10-04 Thread Wei Yang
On Fri, Oct 04, 2019 at 07:33:53PM +0300, Konstantin Khlebnikov wrote: >On 04/10/2019 19.06, Wei Yang wrote: >> In function __anon_vma_prepare(), we will try to find anon_vma if it is >> possible to reuse it. While on fork, the logic is different. >> >> Since commit 5beb49305251 ("mm: change

Re: [PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork

2019-10-04 Thread Wei Yang
On Fri, Oct 04, 2019 at 09:11:20AM -0700, Matthew Wilcox wrote: >On Sat, Oct 05, 2019 at 12:06:32AM +0800, Wei Yang wrote: >> After this change, kernel build test reduces 20% anon_vma allocation. > >But does it have any effect on elapsed time or peak memory consumption? I didn't evaluate these

Re: [PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork

2019-10-04 Thread Konstantin Khlebnikov
On 04/10/2019 19.06, Wei Yang wrote: In function __anon_vma_prepare(), we will try to find anon_vma if it is possible to reuse it. While on fork, the logic is different. Since commit 5beb49305251 ("mm: change anon_vma linking to fix multi-process server scalability issue"), function

Re: [PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork

2019-10-04 Thread Matthew Wilcox
On Sat, Oct 05, 2019 at 12:06:32AM +0800, Wei Yang wrote: > After this change, kernel build test reduces 20% anon_vma allocation. But does it have any effect on elapsed time or peak memory consumption?

[PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork

2019-10-04 Thread Wei Yang
In function __anon_vma_prepare(), we will try to find anon_vma if it is possible to reuse it. While on fork, the logic is different. Since commit 5beb49305251 ("mm: change anon_vma linking to fix multi-process server scalability issue"), function anon_vma_clone() tries to allocate new anon_vma