From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51]) by kanga.kvack.org (Postfix) with SMTP id 212436B004D for ; Fri, 13 Nov 2009 11:38:13 -0500 (EST) Received: from m2.gw.fujitsu.co.jp ([10.0.50.72]) by fgwmail5.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id nADGc7DH027834 for (envelope-from kamezawa.hiroyu@jp.fujitsu.com); Sat, 14 Nov 2009 01:38:08 +0900 Received: from smail (m2 [127.0.0.1]) by outgoing.m2.gw.fujitsu.co.jp (Postfix) with ESMTP id A0AB045DE51 for ; Sat, 14 Nov 2009 01:38:07 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (s2.gw.fujitsu.co.jp [10.0.50.92]) by m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 69A8345DE4E for ; Sat, 14 Nov 2009 01:38:07 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id 53BD5EF8002 for ; Sat, 14 Nov 2009 01:38:07 +0900 (JST) Received: from ml11.s.css.fujitsu.com (ml11.s.css.fujitsu.com [10.249.87.101]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id 068C0E78001 for ; Sat, 14 Nov 2009 01:38:07 +0900 (JST) Message-ID: In-Reply-To: <28c262360911130820r34d2d2d2jf2ca754447eb9f5@mail.gmail.com> References: <20091113163544.d92561c7.kamezawa.hiroyu@jp.fujitsu.com> <28c262360911130820r34d2d2d2jf2ca754447eb9f5@mail.gmail.com> Date: Sat, 14 Nov 2009 01:38:06 +0900 (JST) Subject: Re: [RFC MM] speculative page fault From: "KAMEZAWA Hiroyuki" MIME-Version: 1.0 Content-Type: text/plain;charset=iso-2022-jp Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org To: Minchan Kim Cc: KAMEZAWA Hiroyuki , cl@linux-foundation.org, "linux-mm@kvack.org" List-ID: Minchan Kim wrote: > On Fri, Nov 13, 2009 at 4:35 PM, KAMEZAWA Hiroyuki > wrote: >> This is just a toy patch inspied by on Christoph's mmap_sem works. >> Only for my hobby, now. >> >> Not well tested. So please look into only if you have time. >> >> My multi-thread page fault test program shows some improvement. >> But I doubt my test ;) Do you have recommended benchmarks for parallel >> page-faults ? >> >> Counting # of page faults per 60sec. See page-faults. bigger is better. >> Test on x86-64 8cpus. >> >> [Before] >>  474441.541914  task-clock-msecs         #      7.906 CPUs >>          10318  context-switches         #      0.000 M/sec >>             10  CPU-migrations           #      0.000 M/sec >>       15816787  page-faults              #      0.033 M/sec >>  1485219138381  cycles                   #   3130.458 M/sec  (scaled from 69.99%) >>   295669524399  instructions             #      0.199 IPC    (scaled from 79.98%) >>    57658291915  branches                 #    121.529 M/sec  (scaled from 79.98%) >>      798567455  branch-misses            #      1.385 %      (scaled from 79.98%) >>     2458780947  cache-references         #      5.182 M/sec  (scaled from 20.02%) >>      844605496  cache-misses             #      1.780 M/sec  (scaled from 20.02%) >> >> [After] >> 471166.582784  task-clock-msecs         #      7.852 CPUs >>          10378  context-switches         #      0.000 M/sec >>             10  CPU-migrations           #      0.000 M/sec >>       37950235  page-faults              #      0.081 M/sec >>  1463000664470  cycles                   #   3105.060 M/sec  (scaled from 70.32%) >>   346531590054  instructions             #      0.237 IPC    (scaled from 80.20%) >>    63309364882  branches                 #    134.367 M/sec  (scaled from 80.19%) >>      448256258  branch-misses            #      0.708 %      (scaled from 80.20%) >>     2601112130  cache-references         #      5.521 M/sec  (scaled from 19.81%) >>      872978619  cache-misses             #      1.853 M/sec  (scaled from 19.80%) >> > > Looks amazing. page fault is the two times faster than old. Yes, I amazed and now, doubts my patch or test-program ;) > What's your test program? > This one. http://marc.info/?l=linux-mm&m=125747798627503&w=2 (I might modify..but not far from this.) > I think per thread vma cache is effective as well as speculative lock. > yes, I hope so. >> Main concept of this patch is >>  - Do page fault without taking mm->mmap_sem until some modification in vma happens. >>  - All page fault via get_user_pages() should have to take mmap_sem. >>  - find_vma()/rb_tree must be walked under proper locks. For avoiding that, use >>   per-thread cache. >> >> It seems I don't have enough time to update this, more. >> So, I dump patches here just for share. > > I think this is good embedded device as well as big thread environment > like google. > Some embedded device has big threads. That's because design issue of > migration from RTOS > to Linux. Thread model makes system design easier since threads share > address space like RTOS. > I know it's bad design. but At a loss, it's real problem. > > I support this idea. > Thanks, Kame. Thank you for your interests and review. My cocerns is delaying to free vma might cause some problem (this breaks some assumptions..,) I wonder others might have another idea to improve find_vma(), hopefully in lockless style. Regards, -Kame -- 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/ . Don't email: email@kvack.org