linux-kernel - Re: [PATCH 5/5] proc: export more page flags in /proc/kpageflags

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090428110319.GC25347@elte.hu>
Date:	Tue, 28 Apr 2009 13:03:19 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Wu Fengguang <fengguang.wu@...el.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Larry Woodman <lwoodman@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Matt Mackall <mpm@...enic.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH 5/5] proc: export more page flags in /proc/kpageflags


* Pekka Enberg <penberg@...helsinki.fi> wrote:

> Hi Ingo,
> 
> On Tue, Apr 28, 2009 at 12:36 PM, Ingo Molnar <mingo@...e.hu> wrote:
> > I 'integrate' traces all the time to get summary counts. This series
> > of dynamic events:
> >
> >  allocation
> >  page count up
> >  page count up
> >  page count down
> >  page count up
> >  page count up
> >  page count up
> >  page count up
> >
> > integrates into: "page count is 6".
> >
> > Note that "integration" can be done wholly in the kernel too, 
> > without going to the overhead of streaming all dynamic events to 
> > user-space, just to summarize data into counts, in-kernel. That 
> > is what the ftrace statistics framework and various ftrace 
> > plugins are about.
> >
> > Also, it might make sense to extend the framework with a series 
> > of 'get current object state' events when tracing is turned on. 
> > A special case of _that_ would in essence be what the /proc hack 
> > does now - just expressed in a much more generic, and a much 
> > more usable form.
> 
> 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.

it depends on the level of integration. If the integration is done 
right at the tracepoint callback, performance overhead will be very 
small. If everything is traced and then streamed to user-space then 
there is going to be noticeable overhead starting somewhere around a 
few hundred thousand events per second per cpu.

Note that the 'get object state' approach i outlined above in the 
final paragraph has no runtime overhead at all. As long as 'object 
state' only covers fields that we maintain already for normal kernel 
functionality, it costs nothing to allow the passive sampling of 
that state. The /proc patch is a subset of such a facility in 
essence.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/