[patch 0/4] Linux Kernel Markers for 2.6.23-rc6-mm1
Hi Andrew, Here are the updated Linux Kernel Markers. It depends on : Text Edit Lock Immediate Values Sorted module list Merge Kconfig instrumentation menu It applies to 2.6.23-rc4-mm1, in this order: linux-kernel-markers-architecture-independent-code.patch linux-kernel-markers-instrumentation-menu.patch linux-kernel-markers-documentation.patch linux-kernel-markers-port-blktrace-to-markers.patch You can find a tarball of this patch and all its dependencies at: http://ltt.polymtl.ca/markers/markers-patches-for-2.6.23-rc6-mm1-18-09-2007.tar.bz2 Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/4] Linux Kernel Markers for 2.6.23-rc6-mm1
Hi Andrew, Here are the updated Linux Kernel Markers. It depends on : Text Edit Lock Immediate Values Sorted module list Merge Kconfig instrumentation menu It applies to 2.6.23-rc4-mm1, in this order: linux-kernel-markers-architecture-independent-code.patch linux-kernel-markers-instrumentation-menu.patch linux-kernel-markers-documentation.patch linux-kernel-markers-port-blktrace-to-markers.patch You can find a tarball of this patch and all its dependencies at: http://ltt.polymtl.ca/markers/markers-patches-for-2.6.23-rc6-mm1-18-09-2007.tar.bz2 Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/4] Linux Kernel Markers
Hi Andrew, Here are the updated Linux Kernel Markers. It depends on : Text Edit Lock Immediate Values Sorted module list Merge Kconfig instrumentation menu It applies to 2.6.23-rc4-mm1, in this order: linux-kernel-markers-architecture-independent-code.patch linux-kernel-markers-instrumentation-menu.patch linux-kernel-markers-documentation.patch linux-kernel-markers-port-blktrace-to-markers.patch You can find a tarball of this patch and all its dependencies at: http://ltt.polymtl.ca/markers/markers-patches-for-2.6.23-rc4-mm1-17-09-2007.tar.bz2 Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/4] Linux Kernel Markers
Hi Andrew, Here are the updated Linux Kernel Markers. It depends on : Text Edit Lock Immediate Values Sorted module list Merge Kconfig instrumentation menu It applies to 2.6.23-rc4-mm1, in this order: linux-kernel-markers-architecture-independent-code.patch linux-kernel-markers-instrumentation-menu.patch linux-kernel-markers-documentation.patch linux-kernel-markers-port-blktrace-to-markers.patch You can find a tarball of this patch and all its dependencies at: http://ltt.polymtl.ca/markers/markers-patches-for-2.6.23-rc4-mm1-17-09-2007.tar.bz2 Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/4] Linux Kernel Markers
On Thu, 30 Aug 2007 19:12:40 +0200 Christoph Hellwig <[EMAIL PROTECTED]> wrote: > On Mon, Aug 27, 2007 at 12:05:40PM -0400, Mathieu Desnoyers wrote: > > Hi Andrew, > > > > Here are the Linux Kernel Markers for 2.6.23-rc3-mm1. It depends on the > > "immediate values" and on the "sorted module list" patches. > > Andrew, any chance to get this into -mm ASAP so we can have it in > 2.6.24? Well, we're trying. It looks like another release of these patches will be needed, so I'll have a shot at integrating those. Judging by the number and severity of the bug reports which seem to be flying past, 2.6.23 isn't exactly imminent. And I've been basically off the air this week due lack of electricity (building work). And next week won't be seeing a storm of activity.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/4] Linux Kernel Markers
On Mon, Aug 27, 2007 at 12:05:40PM -0400, Mathieu Desnoyers wrote:
> Hi Andrew,
>
> Here are the Linux Kernel Markers for 2.6.23-rc3-mm1. It depends on the
> "immediate values" and on the "sorted module list" patches.
Andrew, any chance to get this into -mm ASAP so we can have it in
2.6.24?
Just in case anyone wonders what this is usefulfor I've ported my
hacking spu tracing code to it, and if markers get in I'd push a cleaned
up version of this in the tree of the benefit of everyone trying to
follow what's going on in the spufs code. Similarly I'd like to port
the xfs tracing code over to it which is very helpful in trying to
debug filesystem issues.
Note that in this patch the actual logging code is rather nasty
hand-crafted code lifted from the tcp probe in tree which would benefit
of going away in favour of more general tracing code aswell.
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/Makefile
===
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/Makefile 2007-08-30
18:46:07.0 +0200
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/Makefile2007-08-30
18:46:40.0 +0200
@@ -4,6 +4,8 @@ obj-$(CONFIG_SPU_FS) += spufs.o
spufs-y += inode.o file.o context.o syscalls.o coredump.o
spufs-y += sched.o backing_ops.o hw_ops.o run.o gang.o
+obj-m += sputrace.o
+
# Rules to build switch.o with the help of SPU tool chain
SPU_CROSS := spu-
SPU_CC := $(SPU_CROSS)gcc
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/sched.c
===
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/sched.c2007-08-30
18:46:38.0 +0200
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/sched.c 2007-08-30
18:46:40.0 +0200
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
@@ -224,8 +225,8 @@ EXPORT_SYMBOL_GPL(spu_switch_event_unreg
*/
static void spu_bind_context(struct spu *spu, struct spu_context *ctx)
{
- pr_debug("%s: pid=%d SPU=%d NODE=%d\n", __FUNCTION__, current->pid,
-spu->number, spu->node);
+ spu_context_trace(spu_bind_context__enter, ctx, spu);
+
spuctx_switch_state(ctx, SPU_UTIL_SYSTEM);
if (ctx->flags & SPU_CREATE_NOSCHED)
@@ -412,8 +413,8 @@ static int has_affinity(struct spu_conte
*/
static void spu_unbind_context(struct spu *spu, struct spu_context *ctx)
{
- pr_debug("%s: unbind pid=%d SPU=%d NODE=%d\n", __FUNCTION__,
-spu->pid, spu->number, spu->node);
+ spu_context_trace(spu_unbind_context__enter, ctx, spu);
+
spuctx_switch_state(ctx, SPU_UTIL_SYSTEM);
if (spu->ctx->flags & SPU_CREATE_NOSCHED)
@@ -514,6 +515,8 @@ static struct spu *spu_get_idle(struct s
struct spu *spu;
int node, n;
+ spu_context_nospu_trace(spu_get_idle__enter, ctx);
+
if (has_affinity(ctx)) {
node = ctx->gang->aff_ref_spu->node;
@@ -522,7 +525,7 @@ static struct spu *spu_get_idle(struct s
if (spu && spu->alloc_state == SPU_FREE)
goto found;
mutex_unlock(_spu_info[node].list_mutex);
- return NULL;
+ goto not_found;
}
node = cpu_to_node(raw_smp_processor_id());
@@ -539,12 +542,14 @@ static struct spu *spu_get_idle(struct s
mutex_unlock(_spu_info[node].list_mutex);
}
+ not_found:
+ spu_context_nospu_trace(spu_get_idle__not_found, ctx);
return NULL;
found:
spu->alloc_state = SPU_USED;
mutex_unlock(_spu_info[node].list_mutex);
- pr_debug("Got SPU %d %d\n", spu->number, spu->node);
+ spu_context_trace(spu_get_idle__found, ctx, spu);
spu_init_channels(spu);
return spu;
}
@@ -561,6 +566,8 @@ static struct spu *find_victim(struct sp
struct spu *spu;
int node, n;
+ spu_context_nospu_trace(spu_find_vitim__enter, ctx);
+
/*
* Look for a possible preemption candidate on the local node first.
* If there is no candidate look at the other nodes. This isn't
@@ -718,6 +725,8 @@ static int __spu_deactivate(struct spu_c
if (new || force) {
int node = spu->node;
+ spu_context_trace(__spu_deactivate__unload, ctx, spu);
+
mutex_lock(_spu_info[node].list_mutex);
spu_unbind_context(spu, ctx);
spu->alloc_state = SPU_FREE;
@@ -745,6 +754,7 @@ static int __spu_deactivate(struct spu_c
*/
void spu_deactivate(struct spu_context *ctx)
{
+ spu_context_nospu_trace(spu_deactivate__enter, ctx);
__spu_deactivate(ctx, 1, MAX_PRIO);
}
@@ -758,6 +768,7 @@ void spu_deactivate(struct spu_context *
*/
void spu_yield(struct spu_context *ctx)
{
+ spu_context_nospu_trace(spu_yield__enter, ctx);
if
Re: [patch 0/4] Linux Kernel Markers
On Mon, Aug 27, 2007 at 12:05:40PM -0400, Mathieu Desnoyers wrote:
Hi Andrew,
Here are the Linux Kernel Markers for 2.6.23-rc3-mm1. It depends on the
immediate values and on the sorted module list patches.
Andrew, any chance to get this into -mm ASAP so we can have it in
2.6.24?
Just in case anyone wonders what this is usefulfor I've ported my
hacking spu tracing code to it, and if markers get in I'd push a cleaned
up version of this in the tree of the benefit of everyone trying to
follow what's going on in the spufs code. Similarly I'd like to port
the xfs tracing code over to it which is very helpful in trying to
debug filesystem issues.
Note that in this patch the actual logging code is rather nasty
hand-crafted code lifted from the tcp probe in tree which would benefit
of going away in favour of more general tracing code aswell.
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/Makefile
===
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/Makefile 2007-08-30
18:46:07.0 +0200
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/Makefile2007-08-30
18:46:40.0 +0200
@@ -4,6 +4,8 @@ obj-$(CONFIG_SPU_FS) += spufs.o
spufs-y += inode.o file.o context.o syscalls.o coredump.o
spufs-y += sched.o backing_ops.o hw_ops.o run.o gang.o
+obj-m += sputrace.o
+
# Rules to build switch.o with the help of SPU tool chain
SPU_CROSS := spu-
SPU_CC := $(SPU_CROSS)gcc
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/sched.c
===
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/sched.c2007-08-30
18:46:38.0 +0200
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/sched.c 2007-08-30
18:46:40.0 +0200
@@ -39,6 +39,7 @@
#include linux/pid_namespace.h
#include linux/proc_fs.h
#include linux/seq_file.h
+#include linux/marker.h
#include asm/io.h
#include asm/mmu_context.h
@@ -224,8 +225,8 @@ EXPORT_SYMBOL_GPL(spu_switch_event_unreg
*/
static void spu_bind_context(struct spu *spu, struct spu_context *ctx)
{
- pr_debug(%s: pid=%d SPU=%d NODE=%d\n, __FUNCTION__, current-pid,
-spu-number, spu-node);
+ spu_context_trace(spu_bind_context__enter, ctx, spu);
+
spuctx_switch_state(ctx, SPU_UTIL_SYSTEM);
if (ctx-flags SPU_CREATE_NOSCHED)
@@ -412,8 +413,8 @@ static int has_affinity(struct spu_conte
*/
static void spu_unbind_context(struct spu *spu, struct spu_context *ctx)
{
- pr_debug(%s: unbind pid=%d SPU=%d NODE=%d\n, __FUNCTION__,
-spu-pid, spu-number, spu-node);
+ spu_context_trace(spu_unbind_context__enter, ctx, spu);
+
spuctx_switch_state(ctx, SPU_UTIL_SYSTEM);
if (spu-ctx-flags SPU_CREATE_NOSCHED)
@@ -514,6 +515,8 @@ static struct spu *spu_get_idle(struct s
struct spu *spu;
int node, n;
+ spu_context_nospu_trace(spu_get_idle__enter, ctx);
+
if (has_affinity(ctx)) {
node = ctx-gang-aff_ref_spu-node;
@@ -522,7 +525,7 @@ static struct spu *spu_get_idle(struct s
if (spu spu-alloc_state == SPU_FREE)
goto found;
mutex_unlock(cbe_spu_info[node].list_mutex);
- return NULL;
+ goto not_found;
}
node = cpu_to_node(raw_smp_processor_id());
@@ -539,12 +542,14 @@ static struct spu *spu_get_idle(struct s
mutex_unlock(cbe_spu_info[node].list_mutex);
}
+ not_found:
+ spu_context_nospu_trace(spu_get_idle__not_found, ctx);
return NULL;
found:
spu-alloc_state = SPU_USED;
mutex_unlock(cbe_spu_info[node].list_mutex);
- pr_debug(Got SPU %d %d\n, spu-number, spu-node);
+ spu_context_trace(spu_get_idle__found, ctx, spu);
spu_init_channels(spu);
return spu;
}
@@ -561,6 +566,8 @@ static struct spu *find_victim(struct sp
struct spu *spu;
int node, n;
+ spu_context_nospu_trace(spu_find_vitim__enter, ctx);
+
/*
* Look for a possible preemption candidate on the local node first.
* If there is no candidate look at the other nodes. This isn't
@@ -718,6 +725,8 @@ static int __spu_deactivate(struct spu_c
if (new || force) {
int node = spu-node;
+ spu_context_trace(__spu_deactivate__unload, ctx, spu);
+
mutex_lock(cbe_spu_info[node].list_mutex);
spu_unbind_context(spu, ctx);
spu-alloc_state = SPU_FREE;
@@ -745,6 +754,7 @@ static int __spu_deactivate(struct spu_c
*/
void spu_deactivate(struct spu_context *ctx)
{
+ spu_context_nospu_trace(spu_deactivate__enter, ctx);
__spu_deactivate(ctx, 1, MAX_PRIO);
}
@@ -758,6 +768,7 @@ void spu_deactivate(struct spu_context *
*/
void spu_yield(struct spu_context *ctx)
{
+
Re: [patch 0/4] Linux Kernel Markers
On Thu, 30 Aug 2007 19:12:40 +0200 Christoph Hellwig [EMAIL PROTECTED] wrote: On Mon, Aug 27, 2007 at 12:05:40PM -0400, Mathieu Desnoyers wrote: Hi Andrew, Here are the Linux Kernel Markers for 2.6.23-rc3-mm1. It depends on the immediate values and on the sorted module list patches. Andrew, any chance to get this into -mm ASAP so we can have it in 2.6.24? Well, we're trying. It looks like another release of these patches will be needed, so I'll have a shot at integrating those. Judging by the number and severity of the bug reports which seem to be flying past, 2.6.23 isn't exactly imminent. And I've been basically off the air this week due lack of electricity (building work). And next week won't be seeing a storm of activity.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/4] Linux Kernel Markers
Hi Andrew, Here are the Linux Kernel Markers for 2.6.23-rc3-mm1. It depends on the "immediate values" and on the "sorted module list" patches. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/4] Linux Kernel Markers
Hi Andrew, Here are the Linux Kernel Markers for 2.6.23-rc3-mm1. It depends on the immediate values and on the sorted module list patches. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/4] Linux Kernel Markers
Hi Andrew, Here is the new version of the kernel markers. Changes since last post: - Documentation fixes. Applies to 2.6.23-rc2-mm2, in this order: linux-kernel-markers-architecture-independent-code.patch linux-kernel-markers-kconfig-menus.patch linux-kernel-markers-documentation.patch linux-kernel-markers-port-blktrace-to-markers.patch Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/4] Linux Kernel Markers
Hi Andrew, Here is the new version of the kernel markers. Changes since last post: - Documentation fixes. Applies to 2.6.23-rc2-mm2, in this order: linux-kernel-markers-architecture-independent-code.patch linux-kernel-markers-kconfig-menus.patch linux-kernel-markers-documentation.patch linux-kernel-markers-port-blktrace-to-markers.patch Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/4] Linux Kernel Markers
Hi Andrew, Here is the latest version of the Linux Kernel Markers. It applies on top of 2.6.23-rc2-mm2 in this order: linux-kernel-markers-architecture-independent-code.patch linux-kernel-markers-kconfig-menus.patch linux-kernel-markers-documentation.patch linux-kernel-markers-port-blktrace-to-markers.patch It depends on the Immediate Values and Sorted Seq File patches. (note the the Immediate values patch depends on the text edit lock patch). Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/4] Linux Kernel Markers
Hi Andrew, Here is the latest version of the Linux Kernel Markers. It applies on top of 2.6.23-rc2-mm2 in this order: linux-kernel-markers-architecture-independent-code.patch linux-kernel-markers-kconfig-menus.patch linux-kernel-markers-documentation.patch linux-kernel-markers-port-blktrace-to-markers.patch It depends on the Immediate Values and Sorted Seq File patches. (note the the Immediate values patch depends on the text edit lock patch). Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/4] Linux Kernel Markers
Hi Andrew, Here is the latest version of the Linux Kernel Markers. I removed superfluous features that brought more complexity than needed. It applies to 2.6.22-rc6-mm1. It depends on the Immediate Values. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/4] Linux Kernel Markers
Hi Andrew, Here is the latest version of the Linux Kernel Markers. I removed superfluous features that brought more complexity than needed. It applies to 2.6.22-rc6-mm1. It depends on the Immediate Values. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/4] Linux Kernel Markers
* Frank Ch. Eigler ([EMAIL PROTECTED]) wrote: > Mathieu Desnoyers <[EMAIL PROTECTED]> writes: > > > This updated version of the Linux Kernel Markers mostly adds a unique 16 > > bits > > per marker ID and a per-probe marker group. [...] > Hello, > Could you motivate this part better? It is not covered in the > documentation patch. > > It seems to be a way of having a marker handling (callback) module > give alternate names/ids to markers. If so, why, considering that > there is already a private void* callback parameter available to pass > data back to itself through? > The original reason was to get rid of a supplementary kmalloc() for each active marker. However, I just noticed that I could pack my private data in a slab cache, which makes the problem go away. I am therefore removing IDs and groups from the markers.. they don't really belong to this low-level infrastructure anyway, so this is all better. > Also, what if different marker handling modules want to set different > id/group numbers on the same set of markers? > The way I see things now is to provide the simplest way to do the job, without over-design. Clearly, putting the IDs and groups there was not the best idea. I also think it will be up to a "tee" callback module to implement a list of handlers (notifiers). However, supporting such a list of handlers should not be a requirement for the low-level markers, since has a significant performance impact which can be unwanted in the common case (only one probe connected to a marker). Mathieu > - FChE -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/4] Linux Kernel Markers
* Frank Ch. Eigler ([EMAIL PROTECTED]) wrote: Mathieu Desnoyers [EMAIL PROTECTED] writes: This updated version of the Linux Kernel Markers mostly adds a unique 16 bits per marker ID and a per-probe marker group. [...] Hello, Could you motivate this part better? It is not covered in the documentation patch. It seems to be a way of having a marker handling (callback) module give alternate names/ids to markers. If so, why, considering that there is already a private void* callback parameter available to pass data back to itself through? The original reason was to get rid of a supplementary kmalloc() for each active marker. However, I just noticed that I could pack my private data in a slab cache, which makes the problem go away. I am therefore removing IDs and groups from the markers.. they don't really belong to this low-level infrastructure anyway, so this is all better. Also, what if different marker handling modules want to set different id/group numbers on the same set of markers? The way I see things now is to provide the simplest way to do the job, without over-design. Clearly, putting the IDs and groups there was not the best idea. I also think it will be up to a tee callback module to implement a list of handlers (notifiers). However, supporting such a list of handlers should not be a requirement for the low-level markers, since has a significant performance impact which can be unwanted in the common case (only one probe connected to a marker). Mathieu - FChE -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/4] Linux Kernel Markers
Mathieu Desnoyers <[EMAIL PROTECTED]> writes: > This updated version of the Linux Kernel Markers mostly adds a unique 16 bits > per marker ID and a per-probe marker group. [...] Could you motivate this part better? It is not covered in the documentation patch. It seems to be a way of having a marker handling (callback) module give alternate names/ids to markers. If so, why, considering that there is already a private void* callback parameter available to pass data back to itself through? Also, what if different marker handling modules want to set different id/group numbers on the same set of markers? - FChE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/4] Linux Kernel Markers
Mathieu Desnoyers [EMAIL PROTECTED] writes: This updated version of the Linux Kernel Markers mostly adds a unique 16 bits per marker ID and a per-probe marker group. [...] Could you motivate this part better? It is not covered in the documentation patch. It seems to be a way of having a marker handling (callback) module give alternate names/ids to markers. If so, why, considering that there is already a private void* callback parameter available to pass data back to itself through? Also, what if different marker handling modules want to set different id/group numbers on the same set of markers? - FChE - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/4] Linux Kernel Markers
Please note that this release will apply on 2.6.22-rc6-mm1 and depends on the immediate values patch. * Mathieu Desnoyers ([EMAIL PROTECTED]) wrote: > Hi, > > This updated version of the Linux Kernel Markers mostly adds a unique 16 bits > per marker ID and a per-probe marker group. > > Christoph, I think the only concern that I do not plan to address immediately > is > to provide a complet in-kernel user of the markers (blktrace patch does not > actually use the markers full potential). I have external patches that > provides > that, but I don't want to send too much patches at once. Between providing a > complete marker/tracer stack and sending small incremental patches, I think > the > latter is the choice the better suited. This is however an uneasy problem, > which > looks very much like the chicken and egg problem. :) > > If you have concerns with what I recently added to the markers, or if you > still > strongly feel that I must also send the following patches right away, please > let > me know. > > Mathieu > > -- > Mathieu Desnoyers > Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/4] Linux Kernel Markers
Hi, This updated version of the Linux Kernel Markers mostly adds a unique 16 bits per marker ID and a per-probe marker group. Christoph, I think the only concern that I do not plan to address immediately is to provide a complet in-kernel user of the markers (blktrace patch does not actually use the markers full potential). I have external patches that provides that, but I don't want to send too much patches at once. Between providing a complete marker/tracer stack and sending small incremental patches, I think the latter is the choice the better suited. This is however an uneasy problem, which looks very much like the chicken and egg problem. :) If you have concerns with what I recently added to the markers, or if you still strongly feel that I must also send the following patches right away, please let me know. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/4] Linux Kernel Markers
Hi, This updated version of the Linux Kernel Markers mostly adds a unique 16 bits per marker ID and a per-probe marker group. Christoph, I think the only concern that I do not plan to address immediately is to provide a complet in-kernel user of the markers (blktrace patch does not actually use the markers full potential). I have external patches that provides that, but I don't want to send too much patches at once. Between providing a complete marker/tracer stack and sending small incremental patches, I think the latter is the choice the better suited. This is however an uneasy problem, which looks very much like the chicken and egg problem. :) If you have concerns with what I recently added to the markers, or if you still strongly feel that I must also send the following patches right away, please let me know. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/4] Linux Kernel Markers
Please note that this release will apply on 2.6.22-rc6-mm1 and depends on the immediate values patch. * Mathieu Desnoyers ([EMAIL PROTECTED]) wrote: Hi, This updated version of the Linux Kernel Markers mostly adds a unique 16 bits per marker ID and a per-probe marker group. Christoph, I think the only concern that I do not plan to address immediately is to provide a complet in-kernel user of the markers (blktrace patch does not actually use the markers full potential). I have external patches that provides that, but I don't want to send too much patches at once. Between providing a complete marker/tracer stack and sending small incremental patches, I think the latter is the choice the better suited. This is however an uneasy problem, which looks very much like the chicken and egg problem. :) If you have concerns with what I recently added to the markers, or if you still strongly feel that I must also send the following patches right away, please let me know. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Linux Kernel Markers
Hi Richard, * Richard J Moore ([EMAIL PROTECTED]) wrote: > > > Mathieu Desnoyers <[EMAIL PROTECTED]> wrote on 20/12/2006 > 23:52:16: > > > Hi, > > > > You will find, in the following posts, the latest revision of the Linux > Kernel > > Markers. Due to the need some tracing projects (LTTng, SystemTAP) has of > this > > kind of mechanism, it could be nice to consider it for mainstream > inclusion. > > > > The following patches apply on 2.6.20-rc1-git7. > > > > Signed-off-by : Mathieu Desnoyers <[EMAIL PROTECTED]> > > Mathiue, FWIW I like this idea. A few years ago I implemented something > similar, but that had no explicit clients. Consequently I made my hooks > code more generalized than is needed in practice. I do remember that Karim > reworked the LTT instrumentation to use hooks and it worked fine. > Yes, I think some features you implemented in GKHI, like chained calls to multiple probes, should be implemented in a "probe management module" which would be built on top of the marker infrastructure. One of my goal is to concentrate on having the core right so that, afterward, building on top of it will be easy. > You've got the same optimizations for x86 by modifying an instruction's > immediate operand and thus avoiding a d-cache hit. The only real caveat is > the need to avoid the unsynchronised cross modification erratum. Which > means that all processors will need to issue a serializing operation before > executing a Marker whose state is changed. How is that handled? > Good catch. I thought that modifying only 1 byte would spare us from this errata, but looking at it in detail tells me than it's not the case. I see three different ways to address the problem : 1 - Adding some synchronization code in the marker and using synchronize_sched(). 2 - Using an IPI to make other CPUs busy loop while we change the code and then execute a serializing instruction (iret, cpuid...). 3 - First write an int3 instead of the instruction's first byte. The handler would do the following : int3_handler : single-step the original instruction. iret Secondly, we call an IPI that does a smp_processor_id() on each CPU and wait for them to complete. It will make sure we execute a synchronizing instruction on every CPU even if we do not execute the trap handler. Then, we write the new 2 bytes instruction atomically instead of the int3 and immediate value. I exclude (1) because of the performance impact, (2) because it does not deal with NMIs. It leaves (3). Does it make sense ? > One additional thing we did, which might be useful at some future point, > was adding a /proc interface. We reflected the current instrumentation > though /proc and gave the status of each hook. We even talked about being > able to enable or disabled instrumentation by writing to /proc but I don't > think we ever implemented this. > Adding a /proc output to list the active probes and their callback will be tribial to add to the markers. I think the probe management module should have its /proc file too to list the chains of connected handlers once we get there. > It's high time we settled the issue of instrumentation. It gets my vote, > > Good luck! > > Richard > Thanks, Mathieu > - - > Richard J Moore > IBM Linux Technology Centre > -- OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Linux Kernel Markers
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote on 20/12/2006 23:52:16: > Hi, > > You will find, in the following posts, the latest revision of the Linux Kernel > Markers. Due to the need some tracing projects (LTTng, SystemTAP) has of this > kind of mechanism, it could be nice to consider it for mainstream inclusion. > > The following patches apply on 2.6.20-rc1-git7. > > Signed-off-by : Mathieu Desnoyers <[EMAIL PROTECTED]> Mathiue, FWIW I like this idea. A few years ago I implemented something similar, but that had no explicit clients. Consequently I made my hooks code more generalized than is needed in practice. I do remember that Karim reworked the LTT instrumentation to use hooks and it worked fine. You've got the same optimizations for x86 by modifying an instruction's immediate operand and thus avoiding a d-cache hit. The only real caveat is the need to avoid the unsynchronised cross modification erratum. Which means that all processors will need to issue a serializing operation before executing a Marker whose state is changed. How is that handled? One additional thing we did, which might be useful at some future point, was adding a /proc interface. We reflected the current instrumentation though /proc and gave the status of each hook. We even talked about being able to enable or disabled instrumentation by writing to /proc but I don't think we ever implemented this. It's high time we settled the issue of instrumentation. It gets my vote, Good luck! Richard - - Richard J Moore IBM Linux Technology Centre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Linux Kernel Markers
Mathieu Desnoyers [EMAIL PROTECTED] wrote on 20/12/2006 23:52:16: Hi, You will find, in the following posts, the latest revision of the Linux Kernel Markers. Due to the need some tracing projects (LTTng, SystemTAP) has of this kind of mechanism, it could be nice to consider it for mainstream inclusion. The following patches apply on 2.6.20-rc1-git7. Signed-off-by : Mathieu Desnoyers [EMAIL PROTECTED] Mathiue, FWIW I like this idea. A few years ago I implemented something similar, but that had no explicit clients. Consequently I made my hooks code more generalized than is needed in practice. I do remember that Karim reworked the LTT instrumentation to use hooks and it worked fine. You've got the same optimizations for x86 by modifying an instruction's immediate operand and thus avoiding a d-cache hit. The only real caveat is the need to avoid the unsynchronised cross modification erratum. Which means that all processors will need to issue a serializing operation before executing a Marker whose state is changed. How is that handled? One additional thing we did, which might be useful at some future point, was adding a /proc interface. We reflected the current instrumentation though /proc and gave the status of each hook. We even talked about being able to enable or disabled instrumentation by writing to /proc but I don't think we ever implemented this. It's high time we settled the issue of instrumentation. It gets my vote, Good luck! Richard - - Richard J Moore IBM Linux Technology Centre - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Linux Kernel Markers
Hi Richard, * Richard J Moore ([EMAIL PROTECTED]) wrote: Mathieu Desnoyers [EMAIL PROTECTED] wrote on 20/12/2006 23:52:16: Hi, You will find, in the following posts, the latest revision of the Linux Kernel Markers. Due to the need some tracing projects (LTTng, SystemTAP) has of this kind of mechanism, it could be nice to consider it for mainstream inclusion. The following patches apply on 2.6.20-rc1-git7. Signed-off-by : Mathieu Desnoyers [EMAIL PROTECTED] Mathiue, FWIW I like this idea. A few years ago I implemented something similar, but that had no explicit clients. Consequently I made my hooks code more generalized than is needed in practice. I do remember that Karim reworked the LTT instrumentation to use hooks and it worked fine. Yes, I think some features you implemented in GKHI, like chained calls to multiple probes, should be implemented in a probe management module which would be built on top of the marker infrastructure. One of my goal is to concentrate on having the core right so that, afterward, building on top of it will be easy. You've got the same optimizations for x86 by modifying an instruction's immediate operand and thus avoiding a d-cache hit. The only real caveat is the need to avoid the unsynchronised cross modification erratum. Which means that all processors will need to issue a serializing operation before executing a Marker whose state is changed. How is that handled? Good catch. I thought that modifying only 1 byte would spare us from this errata, but looking at it in detail tells me than it's not the case. I see three different ways to address the problem : 1 - Adding some synchronization code in the marker and using synchronize_sched(). 2 - Using an IPI to make other CPUs busy loop while we change the code and then execute a serializing instruction (iret, cpuid...). 3 - First write an int3 instead of the instruction's first byte. The handler would do the following : int3_handler : single-step the original instruction. iret Secondly, we call an IPI that does a smp_processor_id() on each CPU and wait for them to complete. It will make sure we execute a synchronizing instruction on every CPU even if we do not execute the trap handler. Then, we write the new 2 bytes instruction atomically instead of the int3 and immediate value. I exclude (1) because of the performance impact, (2) because it does not deal with NMIs. It leaves (3). Does it make sense ? One additional thing we did, which might be useful at some future point, was adding a /proc interface. We reflected the current instrumentation though /proc and gave the status of each hook. We even talked about being able to enable or disabled instrumentation by writing to /proc but I don't think we ever implemented this. Adding a /proc output to list the active probes and their callback will be tribial to add to the markers. I think the probe management module should have its /proc file too to list the chains of connected handlers once we get there. It's high time we settled the issue of instrumentation. It gets my vote, Good luck! Richard Thanks, Mathieu - - Richard J Moore IBM Linux Technology Centre -- OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] Linux Kernel Markers
Hi, You will find, in the following posts, the latest revision of the Linux Kernel Markers. Due to the need some tracing projects (LTTng, SystemTAP) has of this kind of mechanism, it could be nice to consider it for mainstream inclusion. The following patches apply on 2.6.20-rc1-git7. Signed-off-by : Mathieu Desnoyers <[EMAIL PROTECTED]> OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] Linux Kernel Markers
Hi, You will find, in the following posts, the latest revision of the Linux Kernel Markers. Due to the need some tracing projects (LTTng, SystemTAP) has of this kind of mechanism, it could be nice to consider it for mainstream inclusion. The following patches apply on 2.6.20-rc1-git7. Signed-off-by : Mathieu Desnoyers [EMAIL PROTECTED] OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
