Em Mon, Oct 29, 2007 at 07:35:15PM -0400, Mathieu Desnoyers escreveu:
> I see no good reason to have so many different adhoc instrumentation
> mechanisms for profiling (sched, vm, oprofile) and tracing (blktrace,
> suspend/resume tracing) all over the place. Merging them in a single
> directory
Em Mon, Oct 29, 2007 at 07:35:15PM -0400, Mathieu Desnoyers escreveu:
I see no good reason to have so many different adhoc instrumentation
mechanisms for profiling (sched, vm, oprofile) and tracing (blktrace,
suspend/resume tracing) all over the place. Merging them in a single
directory seems
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers wrote:
> >I see no good reason to have so many different adhoc instrumentation
> >mechanisms for profiling (sched, vm, oprofile) and tracing (blktrace,
> >suspend/resume tracing) all over the place. Merging them in a single
> >directory
Mathieu Desnoyers wrote:
Putting stuff in instrumentation/ by no way means that it becomes
optional for a subsystem, but merely that it could either export
information useful for kernel instrumentation or have some
infrastructure parts merged with others.
More reason why you should not be
Mathieu Desnoyers wrote:
I see no good reason to have so many different adhoc instrumentation
mechanisms for profiling (sched, vm, oprofile) and tracing (blktrace,
suspend/resume tracing) all over the place. Merging them in a single
directory seems like a good step towards a more generic
On Mon, 29 Oct 2007, Mathieu Desnoyers wrote:
> * Christoph Lameter ([EMAIL PROTECTED]) wrote:
> > On Mon, 29 Oct 2007, Mathieu Desnoyers wrote:
> >
> > > vm/vmstat.c
> >
> > The vm statistics are important for the operation of the VM. They are not
> > optional. So I do not think that they
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers wrote:
> >* Jeff Garzik ([EMAIL PROTECTED]) wrote:
> >>Randy Dunlap wrote:
> >>>On Mon, 29 Oct 2007 17:51:38 -0400 Mathieu Desnoyers wrote:
> >>>
> Hi,
>
> Since we already have the Instrumentation menu in
>
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
> On Mon, 29 Oct 2007, Mathieu Desnoyers wrote:
>
> > vm/vmstat.c
>
> The vm statistics are important for the operation of the VM. They are not
> optional. So I do not think that they fall under the category of
> instrumentation.
But I guess vm
On Mon, 29 Oct 2007, Mathieu Desnoyers wrote:
> vm/vmstat.c
The vm statistics are important for the operation of the VM. They are not
optional. So I do not think that they fall under the category of
instrumentation.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Mathieu Desnoyers wrote:
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
Randy Dunlap wrote:
On Mon, 29 Oct 2007 17:51:38 -0400 Mathieu Desnoyers wrote:
Hi,
Since we already have the Instrumentation menu in
kernel/Kconfig.instrumentation and instrumentation code all over the
kernel tree:
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
> Randy Dunlap wrote:
> >On Mon, 29 Oct 2007 17:51:38 -0400 Mathieu Desnoyers wrote:
> >
> >>Hi,
> >>
> >>Since we already have the Instrumentation menu in
> >>kernel/Kconfig.instrumentation and instrumentation code all over the
> >>kernel tree:
> >>
>
Randy Dunlap wrote:
On Mon, 29 Oct 2007 17:51:38 -0400 Mathieu Desnoyers wrote:
Hi,
Since we already have the Instrumentation menu in
kernel/Kconfig.instrumentation and instrumentation code all over the
kernel tree:
arch/*/oprofile/*.c
kernel/kprobes.c
arch/*/kernel/kprobes.c
kernel/marker.c
On Mon, 29 Oct 2007 17:51:38 -0400 Mathieu Desnoyers wrote:
> Hi,
>
> Since we already have the Instrumentation menu in
> kernel/Kconfig.instrumentation and instrumentation code all over the
> kernel tree:
>
> arch/*/oprofile/*.c
> kernel/kprobes.c
> arch/*/kernel/kprobes.c
> kernel/marker.c
>
On Mon, 29 Oct 2007 17:51:38 -0400 Mathieu Desnoyers wrote:
Hi,
Since we already have the Instrumentation menu in
kernel/Kconfig.instrumentation and instrumentation code all over the
kernel tree:
arch/*/oprofile/*.c
kernel/kprobes.c
arch/*/kernel/kprobes.c
kernel/marker.c
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
Randy Dunlap wrote:
On Mon, 29 Oct 2007 17:51:38 -0400 Mathieu Desnoyers wrote:
Hi,
Since we already have the Instrumentation menu in
kernel/Kconfig.instrumentation and instrumentation code all over the
kernel tree:
arch/*/oprofile/*.c
Mathieu Desnoyers wrote:
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
Randy Dunlap wrote:
On Mon, 29 Oct 2007 17:51:38 -0400 Mathieu Desnoyers wrote:
Hi,
Since we already have the Instrumentation menu in
kernel/Kconfig.instrumentation and instrumentation code all over the
kernel tree:
Randy Dunlap wrote:
On Mon, 29 Oct 2007 17:51:38 -0400 Mathieu Desnoyers wrote:
Hi,
Since we already have the Instrumentation menu in
kernel/Kconfig.instrumentation and instrumentation code all over the
kernel tree:
arch/*/oprofile/*.c
kernel/kprobes.c
arch/*/kernel/kprobes.c
kernel/marker.c
On Mon, 29 Oct 2007, Mathieu Desnoyers wrote:
vm/vmstat.c
The vm statistics are important for the operation of the VM. They are not
optional. So I do not think that they fall under the category of
instrumentation.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Mon, 29 Oct 2007, Mathieu Desnoyers wrote:
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
On Mon, 29 Oct 2007, Mathieu Desnoyers wrote:
vm/vmstat.c
The vm statistics are important for the operation of the VM. They are not
optional. So I do not think that they fall under the
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
Mathieu Desnoyers wrote:
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
Randy Dunlap wrote:
On Mon, 29 Oct 2007 17:51:38 -0400 Mathieu Desnoyers wrote:
Hi,
Since we already have the Instrumentation menu in
kernel/Kconfig.instrumentation and
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
On Mon, 29 Oct 2007, Mathieu Desnoyers wrote:
vm/vmstat.c
The vm statistics are important for the operation of the VM. They are not
optional. So I do not think that they fall under the category of
instrumentation.
But I guess vm stats can
Mathieu Desnoyers wrote:
I see no good reason to have so many different adhoc instrumentation
mechanisms for profiling (sched, vm, oprofile) and tracing (blktrace,
suspend/resume tracing) all over the place. Merging them in a single
directory seems like a good step towards a more generic
Mathieu Desnoyers wrote:
Putting stuff in instrumentation/ by no way means that it becomes
optional for a subsystem, but merely that it could either export
information useful for kernel instrumentation or have some
infrastructure parts merged with others.
More reason why you should not be
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
Mathieu Desnoyers wrote:
I see no good reason to have so many different adhoc instrumentation
mechanisms for profiling (sched, vm, oprofile) and tracing (blktrace,
suspend/resume tracing) all over the place. Merging them in a single
directory seems
24 matches
Mail list logo
