| Message ID | 20191011072256.16275-2-richardw.yang@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v4,1/2] mm/rmap.c: don't reuse anon_vma if we just want a copy | expand |
On 11/10/2019 10.22, 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 anon_vma_clone() > tries to allocate new anon_vma for child process. But the logic here > will allocate a new anon_vma for each vma, even in parent this vma > is mergeable and share the same anon_vma with its sibling. This may do > better for scalability issue, while it is not necessary to do so > especially after interval tree is used. > > Commit 7a3ef208e662 ("mm: prevent endless growth of anon_vma hierarchy") > tries to reuse some anon_vma by counting child anon_vma and attached > vmas. While for those mergeable anon_vmas, we can just reuse it and not > necessary to go through the logic. > > After this change, kernel build test reduces 20% anon_vma allocation. > > Do the same kernel build test, it shows run time in sys reduced 11.6%. > > Origin: > > real 2m50.467s > user 17m52.002s > sys 1m51.953s > > real 2m48.662s > user 17m55.464s > sys 1m50.553s > > real 2m51.143s > user 17m59.687s > sys 1m53.600s > > Patched: > > real 2m39.933s > user 17m1.835s > sys 1m38.802s > > real 2m39.321s > user 17m1.634s > sys 1m39.206s > > real 2m39.575s > user 17m1.420s > sys 1m38.845s > > Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Acked-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> > --- > mm/rmap.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/mm/rmap.c b/mm/rmap.c > index c34414567474..2c13e2bfd393 100644 > --- a/mm/rmap.c > +++ b/mm/rmap.c > @@ -268,6 +268,19 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src) > { > struct anon_vma_chain *avc, *pavc; > struct anon_vma *root = NULL; > + struct vm_area_struct *prev = dst->vm_prev, *pprev = src->vm_prev; > + > + /* > + * If parent share anon_vma with its vm_prev, keep this sharing in in > + * child. > + * > + * 1. Parent has vm_prev, which implies we have vm_prev. > + * 2. Parent and its vm_prev have the same anon_vma. > + */ > + if (!dst->anon_vma && src->anon_vma && > + pprev && pprev->anon_vma == src->anon_vma) > + dst->anon_vma = prev->anon_vma; > + I believe that in present code "prev" cannot be NULL if !dst->anon_vma && src->anon_vma is true. It would be safer to check this explicitly. > > list_for_each_entry_reverse(pavc, &src->anon_vma_chain, same_vma) { > struct anon_vma *anon_vma; >
diff --git a/mm/rmap.c b/mm/rmap.c index c34414567474..2c13e2bfd393 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -268,6 +268,19 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src) { struct anon_vma_chain *avc, *pavc; struct anon_vma *root = NULL; + struct vm_area_struct *prev = dst->vm_prev, *pprev = src->vm_prev; + + /* + * If parent share anon_vma with its vm_prev, keep this sharing in in + * child. + * + * 1. Parent has vm_prev, which implies we have vm_prev. + * 2. Parent and its vm_prev have the same anon_vma. + */ + if (!dst->anon_vma && src->anon_vma && + pprev && pprev->anon_vma == src->anon_vma) + dst->anon_vma = prev->anon_vma; + list_for_each_entry_reverse(pavc, &src->anon_vma_chain, same_vma) { struct anon_vma *anon_vma;
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 for child process. But the logic here will allocate a new anon_vma for each vma, even in parent this vma is mergeable and share the same anon_vma with its sibling. This may do better for scalability issue, while it is not necessary to do so especially after interval tree is used. Commit 7a3ef208e662 ("mm: prevent endless growth of anon_vma hierarchy") tries to reuse some anon_vma by counting child anon_vma and attached vmas. While for those mergeable anon_vmas, we can just reuse it and not necessary to go through the logic. After this change, kernel build test reduces 20% anon_vma allocation. Do the same kernel build test, it shows run time in sys reduced 11.6%. Origin: real 2m50.467s user 17m52.002s sys 1m51.953s real 2m48.662s user 17m55.464s sys 1m50.553s real 2m51.143s user 17m59.687s sys 1m53.600s Patched: real 2m39.933s user 17m1.835s sys 1m38.802s real 2m39.321s user 17m1.634s sys 1m39.206s real 2m39.575s user 17m1.420s sys 1m38.845s Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> --- mm/rmap.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)