From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
"Andrew Morton (commit_signer:15/23=65%)"
<akpm@linux-foundation.org>,
"Hugh Dickins (commit_signer:7/23=30%)" <hughd@google.com>,
"Peter Zijlstra (commit_signer:4/23=17%)"
<a.p.zijlstra@chello.nl>,
"Shaohua Li (commit_signer:3/23=13%)" <shaohua.li@intel.com>
Subject: Re: [PATCH v3] mm: simplify find_vma_prev
Date: Mon, 12 Dec 2011 10:31:57 -0500 [thread overview]
Message-ID: <4EE61E6D.4070401@gmail.com> (raw)
In-Reply-To: <20111212182711.3a072358.kamezawa.hiroyu@jp.fujitsu.com>
(12/12/11 4:27 AM), KAMEZAWA Hiroyuki wrote:
> On Mon, 12 Dec 2011 09:49:30 +0900
> KAMEZAWA Hiroyuki<kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
>> On Fri, 9 Dec 2011 17:48:40 -0500
>> kosaki.motohiro@gmail.com wrote:
>>
>>> From: KOSAKI Motohiro<kosaki.motohiro@jp.fujitsu.com>
>>>
>>> commit 297c5eee37 (mm: make the vma list be doubly linked) added
>>> vm_prev member into vm_area_struct. Therefore we can simplify
>>> find_vma_prev() by using it. Also, this change help to improve
>>> page fault performance because it has strong locality of reference.
>>>
>>> Signed-off-by: KOSAKI Motohiro<kosaki.motohiro@jp.fujitsu.com>
>>
>> Reviewed-by: KAMEZAWA Hiroyuki<kamezawa.hiroyu@jp.fujitsu.com>
>>
>
> Hmm, your work remind me of a patch I tried in past.
> Here is a refleshed one...how do you think ?
>
> ==
> From c0261936fc01322d06425731d33f38b2021e8067 Mon Sep 17 00:00:00 2001
> From: KAMEZAWA Hiroyuki<kamezawa.hiroyu@jp.fujitsu.com>
> Date: Mon, 12 Dec 2011 18:31:19 +0900
> Subject: [PATCH] per thread vma cache.
>
> This is a toy patch. How do you think ?
>
> This is a patch for per-thread mmap_cache without heavy atomic ops.
>
> I'm sure overhead of find_vma() is pretty small in usual application
> and this will not show good improvement. But I think, if we need
> to have cache of vma, it should be per thread rather than per mm.
Agreed. per-thread is better.
> This patch adds thread->mmap_cache, a pointer for vm_area_struct
> and update it appropriately. Because we have no refcnt on vm_area_struct,
> thread->mmap_cache may be a stale pointer. This patch detects stale
> pointer by checking
>
> - thread->mmap_cache is one of SLABs in vm_area_cachep.
> - thread->mmap_cache->vm_mm == mm.
>
> vma->vm_mm will be cleared before kmem_cache_free() by this patch.
Do you mean the cache can make mishit with unrelated vma when freed vma
was reused?
If so, it is most tricky part of this patch, I strongly hope you write
a comment more.
Thank you.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
"Andrew Morton (commit_signer:15/23=65%)"
<akpm@linux-foundation.org>,
"Hugh Dickins (commit_signer:7/23=30%)" <hughd@google.com>,
"Peter Zijlstra (commit_signer:4/23=17%)"
<a.p.zijlstra@chello.nl>,
"Shaohua Li (commit_signer:3/23=13%)" <shaohua.li@intel.com>
Subject: Re: [PATCH v3] mm: simplify find_vma_prev
Date: Mon, 12 Dec 2011 10:31:57 -0500 [thread overview]
Message-ID: <4EE61E6D.4070401@gmail.com> (raw)
In-Reply-To: <20111212182711.3a072358.kamezawa.hiroyu@jp.fujitsu.com>
(12/12/11 4:27 AM), KAMEZAWA Hiroyuki wrote:
> On Mon, 12 Dec 2011 09:49:30 +0900
> KAMEZAWA Hiroyuki<kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
>> On Fri, 9 Dec 2011 17:48:40 -0500
>> kosaki.motohiro@gmail.com wrote:
>>
>>> From: KOSAKI Motohiro<kosaki.motohiro@jp.fujitsu.com>
>>>
>>> commit 297c5eee37 (mm: make the vma list be doubly linked) added
>>> vm_prev member into vm_area_struct. Therefore we can simplify
>>> find_vma_prev() by using it. Also, this change help to improve
>>> page fault performance because it has strong locality of reference.
>>>
>>> Signed-off-by: KOSAKI Motohiro<kosaki.motohiro@jp.fujitsu.com>
>>
>> Reviewed-by: KAMEZAWA Hiroyuki<kamezawa.hiroyu@jp.fujitsu.com>
>>
>
> Hmm, your work remind me of a patch I tried in past.
> Here is a refleshed one...how do you think ?
>
> ==
> From c0261936fc01322d06425731d33f38b2021e8067 Mon Sep 17 00:00:00 2001
> From: KAMEZAWA Hiroyuki<kamezawa.hiroyu@jp.fujitsu.com>
> Date: Mon, 12 Dec 2011 18:31:19 +0900
> Subject: [PATCH] per thread vma cache.
>
> This is a toy patch. How do you think ?
>
> This is a patch for per-thread mmap_cache without heavy atomic ops.
>
> I'm sure overhead of find_vma() is pretty small in usual application
> and this will not show good improvement. But I think, if we need
> to have cache of vma, it should be per thread rather than per mm.
Agreed. per-thread is better.
> This patch adds thread->mmap_cache, a pointer for vm_area_struct
> and update it appropriately. Because we have no refcnt on vm_area_struct,
> thread->mmap_cache may be a stale pointer. This patch detects stale
> pointer by checking
>
> - thread->mmap_cache is one of SLABs in vm_area_cachep.
> - thread->mmap_cache->vm_mm == mm.
>
> vma->vm_mm will be cleared before kmem_cache_free() by this patch.
Do you mean the cache can make mishit with unrelated vma when freed vma
was reused?
If so, it is most tricky part of this patch, I strongly hope you write
a comment more.
Thank you.
next prev parent reply other threads:[~2011-12-12 15:32 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-09 21:23 [PATCH v2] mm: simplify find_vma_prev kosaki.motohiro
2011-12-09 21:23 ` kosaki.motohiro
2011-12-09 21:35 ` Joe Perches
2011-12-09 21:35 ` Joe Perches
2011-12-09 22:48 ` [PATCH v3] " kosaki.motohiro
2011-12-09 22:48 ` kosaki.motohiro
2011-12-12 0:49 ` KAMEZAWA Hiroyuki
2011-12-12 0:49 ` KAMEZAWA Hiroyuki
2011-12-12 9:27 ` KAMEZAWA Hiroyuki
2011-12-12 9:27 ` KAMEZAWA Hiroyuki
2011-12-12 15:31 ` KOSAKI Motohiro [this message]
2011-12-12 15:31 ` KOSAKI Motohiro
2011-12-13 4:25 ` KAMEZAWA Hiroyuki
2011-12-13 4:25 ` KAMEZAWA Hiroyuki
2011-12-12 13:26 ` Michal Hocko
2011-12-12 13:26 ` Michal Hocko
2011-12-12 14:49 ` KOSAKI Motohiro
2011-12-12 14:49 ` KOSAKI Motohiro
2011-12-12 19:15 ` Michal Hocko
2011-12-12 19:15 ` Michal Hocko
2011-12-12 19:24 ` KOSAKI Motohiro
2011-12-12 19:24 ` KOSAKI Motohiro
2011-12-12 19:34 ` KOSAKI Motohiro
2011-12-12 19:34 ` KOSAKI Motohiro
2011-12-09 22:49 ` [PATCH v2] " KOSAKI Motohiro
2011-12-09 22:49 ` KOSAKI Motohiro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EE61E6D.4070401@gmail.com \
--to=kosaki.motohiro@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shaohua.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.