Messages in this thread | | | Date | Tue, 28 Apr 2009 13:03:19 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 5/5] proc: export more page flags in /proc/kpageflags |
| |
* Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> Hi Ingo, > > On Tue, Apr 28, 2009 at 12:36 PM, Ingo Molnar <mingo@elte.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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |