All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Li Zefan <lizf@cn.fujitsu.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
	Arjan van de Ven <arjan@infradead.org>,
	Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>,
	Peter Zijlstra <peterz@infradead.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH 0/5] perf kmem: Add more functions and show more statistics
Date: Tue, 24 Nov 2009 09:34:23 +0100	[thread overview]
Message-ID: <20091124083423.GE21991@elte.hu> (raw)
In-Reply-To: <4B0B937F.4080906@cn.fujitsu.com>


* Li Zefan <lizf@cn.fujitsu.com> wrote:

> Ingo Molnar wrote:
> > * Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> > 
> >> Hi Li,
> >>
> >> On Tue, Nov 24, 2009 at 7:25 AM, Li Zefan <lizf@cn.fujitsu.com> wrote:
> >>> Pekka, do you think we can remove kmemtrace now?
> >> One more use case I forgot to mention: boot time tracing. Much of the 
> >> persistent kernel memory footprint comes from the boot process which 
> >> is why it's important to be able to trace memory allocations 
> >> immediately after kmem_cache_init() has run. Can we make "perf kmem" 
> >> do that? Eduard put most of his efforts into making that work for 
> >> kmemtrace.
> > 
> > Would be lovely if someone looked at perf from that angle (and extended 
> > it).
> > 
> > Another interesting area would be to allow a capture session without a 
> > process context running immediately. (i.e. pre-allocate all the buffers, 
> > use them, for a later 'perf save' to pick it up.)
> > 
> > The two are kind of the same thing conceptually: a boot time trace is a 
> > preallocated 'process context less' recording, to be picked up after 
> > bootup.
> > 
> > [ It also brings us 'stability/persistency of event logging' - i.e. a 
> >   capture session could be started and guaranteed by the kernel to be 
> >   underway, regardless of what user-space does. ]
> > 
> > Btw., Arjan is doing a _lot_ of boot time tracing for Moblin, and he 
> > indicated it in the past that starting a perf recording session from 
> > an initrd is a pretty practical substitute as well. (I've Cc:-ed 
> > Arjan.)
> 
> It would be great if perf can be used for boot time tracing. This 
> needs pretty big work on kernel side.

What would be needed is to open per cpu events right after perf events 
initializes, and allocate memory for output buffers to them.

They would round-robin after that point, and we could use 
perf_event_open() (with a special flag) to 'attach' to them and mmap() 
them - at which point they'd turn into regular objects with a lot of 
boot time data in them.

Perhaps it should be possible to attach/detach from events in a flexible 
way, not just during bootup. (bootup tracing is just a special case of 
it.)

For example a 'flight recorder' could be started by creating the events 
and then detaching from them. Whenever some exception is flagged the 
monitoring context (whatever task that might be at that time - at 
whatever point in the future) could attach to it and save it to a file 
(or send it over any other transport of choice).

This would IMO mix the best of ftrace with the best of perf, for these 
usecases.

[ Certainly not a feature for the faint hearted :-) ]

	Ingo

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu>
To: Li Zefan <lizf@cn.fujitsu.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
	Arjan van de Ven <arjan@infradead.org>,
	Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>,
	Peter Zijlstra <peterz@infradead.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH 0/5] perf kmem: Add more functions and show more statistics
Date: Tue, 24 Nov 2009 09:34:23 +0100	[thread overview]
Message-ID: <20091124083423.GE21991@elte.hu> (raw)
In-Reply-To: <4B0B937F.4080906@cn.fujitsu.com>


* Li Zefan <lizf@cn.fujitsu.com> wrote:

> Ingo Molnar wrote:
> > * Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> > 
> >> Hi Li,
> >>
> >> On Tue, Nov 24, 2009 at 7:25 AM, Li Zefan <lizf@cn.fujitsu.com> wrote:
> >>> Pekka, do you think we can remove kmemtrace now?
> >> One more use case I forgot to mention: boot time tracing. Much of the 
> >> persistent kernel memory footprint comes from the boot process which 
> >> is why it's important to be able to trace memory allocations 
> >> immediately after kmem_cache_init() has run. Can we make "perf kmem" 
> >> do that? Eduard put most of his efforts into making that work for 
> >> kmemtrace.
> > 
> > Would be lovely if someone looked at perf from that angle (and extended 
> > it).
> > 
> > Another interesting area would be to allow a capture session without a 
> > process context running immediately. (i.e. pre-allocate all the buffers, 
> > use them, for a later 'perf save' to pick it up.)
> > 
> > The two are kind of the same thing conceptually: a boot time trace is a 
> > preallocated 'process context less' recording, to be picked up after 
> > bootup.
> > 
> > [ It also brings us 'stability/persistency of event logging' - i.e. a 
> >   capture session could be started and guaranteed by the kernel to be 
> >   underway, regardless of what user-space does. ]
> > 
> > Btw., Arjan is doing a _lot_ of boot time tracing for Moblin, and he 
> > indicated it in the past that starting a perf recording session from 
> > an initrd is a pretty practical substitute as well. (I've Cc:-ed 
> > Arjan.)
> 
> It would be great if perf can be used for boot time tracing. This 
> needs pretty big work on kernel side.

What would be needed is to open per cpu events right after perf events 
initializes, and allocate memory for output buffers to them.

They would round-robin after that point, and we could use 
perf_event_open() (with a special flag) to 'attach' to them and mmap() 
them - at which point they'd turn into regular objects with a lot of 
boot time data in them.

Perhaps it should be possible to attach/detach from events in a flexible 
way, not just during bootup. (bootup tracing is just a special case of 
it.)

For example a 'flight recorder' could be started by creating the events 
and then detaching from them. Whenever some exception is flagged the 
monitoring context (whatever task that might be at that time - at 
whatever point in the future) could attach to it and save it to a file 
(or send it over any other transport of choice).

This would IMO mix the best of ftrace with the best of perf, for these 
usecases.

[ Certainly not a feature for the faint hearted :-) ]

	Ingo

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-11-24  8:34 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-24  5:25 [PATCH 0/5] perf kmem: Add more functions and show more statistics Li Zefan
2009-11-24  5:25 ` Li Zefan
2009-11-24  5:25 ` [PATCH 1/5] perf kmem: Add new option to show raw ip Li Zefan
2009-11-24  5:25   ` Li Zefan
2009-11-24 16:54   ` [tip:perf/core] " tip-bot for Li Zefan
2009-11-24 16:54     ` tip-bot for Li Zefan
2009-11-24  5:26 ` [PATCH 2/5] perf kmem: Default to sort by fragmentation Li Zefan
2009-11-24  5:26   ` Li Zefan
2009-11-24 16:55   ` [tip:perf/core] " tip-bot for Li Zefan
2009-11-24 16:55     ` tip-bot for Li Zefan
2009-11-24  5:26 ` [PATCH 3/5] perf kmem: Collect cross node allocation statistics Li Zefan
2009-11-24  5:26   ` Li Zefan
2009-11-24 16:55   ` [tip:perf/core] " tip-bot for Li Zefan
2009-11-24 16:55     ` tip-bot for Li Zefan
2009-11-24  5:26 ` [PATCH 4/5] perf kmem: Measure kmalloc/kfree CPU ping-pong call-sites Li Zefan
2009-11-24  5:26   ` Li Zefan
2009-11-24 16:55   ` [tip:perf/core] " tip-bot for Li Zefan
2009-11-24 16:55     ` tip-bot for Li Zefan
2009-11-24  5:27 ` [PATCH 5/5] perf kmem: Add help file Li Zefan
2009-11-24  5:27   ` Li Zefan
2009-11-24 16:55   ` [tip:perf/core] " tip-bot for Li Zefan
2009-11-24 16:55     ` tip-bot for Li Zefan
2009-11-24  7:15 ` [PATCH 0/5] perf kmem: Add more functions and show more statistics Pekka Enberg
2009-11-24  7:15   ` Pekka Enberg
2009-11-24  7:34   ` Ingo Molnar
2009-11-24  7:34     ` Ingo Molnar
2009-11-24  7:45     ` Pekka Enberg
2009-11-24  7:45       ` Pekka Enberg
2009-11-24  7:47       ` Ingo Molnar
2009-11-24  7:47         ` Ingo Molnar
2009-11-24  8:04     ` Li Zefan
2009-11-24  8:04       ` Li Zefan
2009-11-24  8:34       ` Ingo Molnar [this message]
2009-11-24  8:34         ` Ingo Molnar
2009-11-24 14:57         ` Arjan van de Ven
2009-11-24 14:57           ` Arjan van de Ven
2009-11-24  7:18 ` Pekka Enberg
2009-11-24  7:18   ` Pekka Enberg
2009-11-24  9:04 ` Ingo Molnar
2009-11-24  9:38   ` Li Zefan
2009-11-24  9:38     ` Li Zefan
2009-11-24 10:07     ` Ingo Molnar
2009-11-24 11:04       ` Li Zefan
2009-11-24 11:04         ` Li Zefan
2009-11-24 20:35         ` Ingo Molnar
2009-11-24 20:35           ` Ingo Molnar
2009-11-24 22:34           ` Ingo Molnar
2009-11-24 22:34             ` Ingo Molnar
2009-11-24 18:49       ` Frederic Weisbecker
2009-11-24 18:49         ` Frederic Weisbecker
2009-11-24 19:38       ` [PATCH] perf: Fix bad software/trace event recursion counting Frederic Weisbecker
2009-11-24 20:36         ` [tip:perf/core] perf_events: " tip-bot for Frederic Weisbecker
2009-11-24 20:48         ` [PATCH] perf: " Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091124083423.GE21991@elte.hu \
    --to=mingo@elte.hu \
    --cc=arjan@infradead.org \
    --cc=eduard.munteanu@linux360.ro \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=penberg@cs.helsinki.fi \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.