From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755541AbZD1KKq (ORCPT ); Tue, 28 Apr 2009 06:10:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755618AbZD1KKf (ORCPT ); Tue, 28 Apr 2009 06:10:35 -0400 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:57943 "EHLO fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757935AbZD1KKc (ORCPT ); Tue, 28 Apr 2009 06:10:32 -0400 From: KOSAKI Motohiro To: Pekka Enberg Subject: Re: [PATCH 5/5] proc: export more page flags in /proc/kpageflags Cc: kosaki.motohiro@jp.fujitsu.com, Ingo Molnar , Andi Kleen , Wu Fengguang , Steven Rostedt , =?ISO-2022-JP?B?RnIbJEJxRXFTGyhCaWM=?= Weisbecker , Larry Woodman , Peter Zijlstra , Eduard - Gabriel Munteanu , Andrew Morton , LKML , Matt Mackall , Alexey Dobriyan , "linux-mm@kvack.org" In-Reply-To: <84144f020904280257j57b5b686k91cc4096a8e5ca29@mail.gmail.com> References: <20090428093621.GD21085@elte.hu> <84144f020904280257j57b5b686k91cc4096a8e5ca29@mail.gmail.com> Message-Id: <20090428190822.EBED.A69D9226@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50 [ja] Date: Tue, 28 Apr 2009 19:10:25 +0900 (JST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > I guess the main question here is whether this approach will scale to > something like kmalloc() or the page allocator in production > environments. For any serious workload, the frequency of events is > going to be pretty high. Immediate Values patch series makes zero-overhead to tracepoint while it's not used. So, We have to implement to stop collect stastics way. it restore zero overhead world. We don't lose any performance by trace. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227]) by kanga.kvack.org (Postfix) with SMTP id 61C076B0047 for ; Tue, 28 Apr 2009 06:10:20 -0400 (EDT) Received: from mt1.gw.fujitsu.co.jp ([10.0.50.74]) by fgwmail7.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id n3SAASjd026911 for (envelope-from kosaki.motohiro@jp.fujitsu.com); Tue, 28 Apr 2009 19:10:28 +0900 Received: from smail (m4 [127.0.0.1]) by outgoing.m4.gw.fujitsu.co.jp (Postfix) with ESMTP id DA91F45DE51 for ; Tue, 28 Apr 2009 19:10:27 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (s4.gw.fujitsu.co.jp [10.0.50.94]) by m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 9727845DE50 for ; Tue, 28 Apr 2009 19:10:27 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 54AC11DB8040 for ; Tue, 28 Apr 2009 19:10:27 +0900 (JST) Received: from m108.s.css.fujitsu.com (m108.s.css.fujitsu.com [10.249.87.108]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 0D89F1DB803C for ; Tue, 28 Apr 2009 19:10:27 +0900 (JST) From: KOSAKI Motohiro Subject: Re: [PATCH 5/5] proc: export more page flags in /proc/kpageflags In-Reply-To: <84144f020904280257j57b5b686k91cc4096a8e5ca29@mail.gmail.com> References: <20090428093621.GD21085@elte.hu> <84144f020904280257j57b5b686k91cc4096a8e5ca29@mail.gmail.com> Message-Id: <20090428190822.EBED.A69D9226@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Date: Tue, 28 Apr 2009 19:10:25 +0900 (JST) Sender: owner-linux-mm@kvack.org To: Pekka Enberg Cc: kosaki.motohiro@jp.fujitsu.com, Ingo Molnar , Andi Kleen , Wu Fengguang , Steven Rostedt , =?ISO-2022-JP?B?RnIbJEJxRXFTGyhCaWM=?= Weisbecker , Larry Woodman , Peter Zijlstra , Eduard - Gabriel Munteanu , Andrew Morton , LKML , Matt Mackall , Alexey Dobriyan , "linux-mm@kvack.org" List-ID: > I guess the main question here is whether this approach will scale to > something like kmalloc() or the page allocator in production > environments. For any serious workload, the frequency of events is > going to be pretty high. Immediate Values patch series makes zero-overhead to tracepoint while it's not used. So, We have to implement to stop collect stastics way. it restore zero overhead world. We don't lose any performance by trace. -- 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