On Wed, 9 Jun 2010 09:47:34 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
> > Looks nice, Kamezawa-San could you please confirm the source of
> > raw_spin_lock_irqsave and trylock from /proc/lock_stat?
> >
> Sure. But above result can be got when lockdep etc..are off.
> (it increase lock overhead)
>
> But yes, new _raw_spin_lock seems strange.
>
Here.
==
------------------------------
&(&mm->page_table_lock)->rlock 20812995 [<ffffffff81124019>] handle_mm_fault+0x7a9/0x9b0
&(&mm->page_table_lock)->rlock 9 [<ffffffff81120c5b>] __pte_alloc+0x4b/0xf0
&(&mm->page_table_lock)->rlock 4 [<ffffffff8112c70d>] anon_vma_prepare+0xad/0x180
&(&mm->page_table_lock)->rlock 83395 [<ffffffff811204b4>] unmap_vmas+0x3c4/0xa60
------------------------------
&(&mm->page_table_lock)->rlock 7 [<ffffffff81120c5b>] __pte_alloc+0x4b/0xf0
&(&mm->page_table_lock)->rlock 20812987 [<ffffffff81124019>] handle_mm_fault+0x7a9/0x9b0
&(&mm->page_table_lock)->rlock 2 [<ffffffff8112c70d>] anon_vma_prepare+0xad/0x180
&(&mm->page_table_lock)->rlock 83408 [<ffffffff811204b4>] unmap_vmas+0x3c4/0xa60
&(&p->alloc_lock)->rlock: 6304532 6308276 0.14 1772.97 7098177.74 23165904 23222238 0.00 1980.76 12445023.62
------------------------
&(&p->alloc_lock)->rlock 6308277 [<ffffffff81153e17>] __mem_cgroup_try_charge+0x327/0x590
------------------------
&(&p->alloc_lock)->rlock 6308277 [<ffffffff81153e17>] __mem_cgroup_try_charge+0x327/0x590
==
Then, new raw_spin_lock is task_lock(). This is because task_lock(mm->owner) makes
cacheline ping pong ;(
So, this is not very good patch for multi-threaded programs, Sigh...
I'll consider how I can get safe access without locks again..
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>