Linux-Next discussions
 help / color / mirror / Atom feed
* Re: linux-next: concerns over the perfmon3 tree
From: stephane eranian @ 2008-11-26 13:27 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, paulus, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin
In-Reply-To: <20081126213449.ab269449.sfr@canb.auug.org.au>

Stephen

On Wed, Nov 26, 2008 at 11:34 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Stephane,
>
> Given the concerns expressed by Ingo, I have dropped the perfmon3 tree
> from linux-next until they have been addressed.  Hopefully that will not
> be loo long.  Let us all know how we can help with this.
>
Thanks for your help. I am fine going through the review process once again.
I am just hoping we can still make the 2.6.29 target.

^ permalink raw reply

* Re: linux-next: concerns over the perfmon3 tree
From: stephane eranian @ 2008-11-26 13:25 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, linux-next, paulus, Andrew Morton,
	Thomas Gleixner, H. Peter Anvin
In-Reply-To: <20081126104726.GA8580@elte.hu>

Ingo,

On Wed, Nov 26, 2008 at 11:47 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi Stephane,
>>
>> Given the concerns expressed by Ingo, I have dropped the perfmon3
>> tree from linux-next until they have been addressed.  Hopefully that
>> will not be loo long.  Let us all know how we can help with this.
>
> Thanks, we'll try to finish the review ASAP (today+tomorrow) so that
> it can be added back in 1-2 days. And it's sensible to keep it in the
> separate perfmon3 tree as well (as long as it's not rebased) - that's
> a convenient initial structure for new features.
>

I think I am missing something about rebasing. Are you saying you want
the patches to stay with the same tree until it is reviewed thoroughly? So
far I have used Linus' v2.6.28-rcXX tree as it evolves at a pace I can follow.
Is that okay?

> ( and the powerpc bits would be nice as well, they seem to be missing
>  from the current lineup - the more architectures keep hitting on
>  that code, the better the end result. )
>

The fully featured perfmon3 code (available as a branch of my kernel.org tree)
has all the architectures we currently support. There is some overlap with the
patchset posted on LKML. I focused on x86 because this is the key architecture
with a lot of demands. It should not be very difficult to derive the
powerpc patchset
from the fully featured git branch, same goes for MIPS, and SPARC. IA-64 will be
a bit more challenging because they already have a much older version
of perfmon2.
Switching IA-64 to perfmon3 now, would cause lots of perfmon2 features
to disappear
(e.g., sampling, system-wide).

^ permalink raw reply

* [PATCH] Blktrace : conversion to tracepoint define
From: Mathieu Desnoyers @ 2008-11-26 11:06 UTC (permalink / raw)
  To: Jens Axboe, Ingo Molnar
  Cc: Stephen Rothwell, linux-next, Arnaldo Carvalho de Melo
In-Reply-To: <20081126104700.GI26308@kernel.dk>

Here is the conversion to the new tracepoint API, which applies to -tip
after the patch you just emailed.

Mathieu


Blktrace : conversion to tracepoint define

Adapt declaration/definitions of blktrace tracepoints to the new tracepoint API.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: Arnaldo Carvalho de Melo <acme@redhat.com>
CC: 'Ingo Molnar' <mingo@elte.hu>
CC: Jens Axboe <jens.axboe@oracle.com>
CC: Arnaldo Carvalho de Melo <acme@redhat.com>
CC: Stephen Rothwell <sfr@canb.auug.org.au>
---
 block/blk-core.c      |   13 +++++++++++++
 block/elevator.c      |    3 +++
 drivers/md/dm.c       |    2 ++
 fs/bio.c              |    2 ++
 include/trace/block.h |   34 +++++++++++++++++-----------------
 mm/bounce.c           |    2 ++
 6 files changed, 39 insertions(+), 17 deletions(-)

Index: linux.trees.git/mm/bounce.c
===================================================================
--- linux.trees.git.orig/mm/bounce.c	2008-11-26 05:49:40.000000000 -0500
+++ linux.trees.git/mm/bounce.c	2008-11-26 05:50:08.000000000 -0500
@@ -22,6 +22,8 @@
 
 static mempool_t *page_pool, *isa_page_pool;
 
+DEFINE_TRACE(block_bio_bounce);
+
 #ifdef CONFIG_HIGHMEM
 static __init int init_emergency_pool(void)
 {
Index: linux.trees.git/fs/bio.c
===================================================================
--- linux.trees.git.orig/fs/bio.c	2008-11-26 05:49:40.000000000 -0500
+++ linux.trees.git/fs/bio.c	2008-11-26 05:50:25.000000000 -0500
@@ -29,6 +29,8 @@
 #include <trace/block.h>
 #include <scsi/sg.h>		/* for struct sg_iovec */
 
+DEFINE_TRACE(block_split);
+
 static struct kmem_cache *bio_slab __read_mostly;
 
 static mempool_t *bio_split_pool __read_mostly;
Index: linux.trees.git/drivers/md/dm.c
===================================================================
--- linux.trees.git.orig/drivers/md/dm.c	2008-11-26 05:49:40.000000000 -0500
+++ linux.trees.git/drivers/md/dm.c	2008-11-26 05:50:08.000000000 -0500
@@ -52,6 +52,8 @@ struct dm_target_io {
 	union map_info info;
 };
 
+DEFINE_TRACE(block_bio_complete);
+
 union map_info *dm_get_mapinfo(struct bio *bio)
 {
 	if (bio && bio->bi_private)
Index: linux.trees.git/block/blk-core.c
===================================================================
--- linux.trees.git.orig/block/blk-core.c	2008-11-26 05:49:40.000000000 -0500
+++ linux.trees.git/block/blk-core.c	2008-11-26 05:50:08.000000000 -0500
@@ -32,6 +32,19 @@
 
 #include "blk.h"
 
+DEFINE_TRACE(block_plug);
+DEFINE_TRACE(block_unplug_io);
+DEFINE_TRACE(block_unplug_timer);
+DEFINE_TRACE(block_getrq);
+DEFINE_TRACE(block_sleeprq);
+DEFINE_TRACE(block_rq_requeue);
+DEFINE_TRACE(block_bio_backmerge);
+DEFINE_TRACE(block_bio_frontmerge);
+DEFINE_TRACE(block_bio_queue);
+DEFINE_TRACE(block_rq_complete);
+DEFINE_TRACE(block_remap);	/* Also used in drivers/md/dm.c */
+EXPORT_TRACEPOINT_SYMBOL_GPL(block_remap);
+
 static int __make_request(struct request_queue *q, struct bio *bio);
 
 /*
Index: linux.trees.git/block/elevator.c
===================================================================
--- linux.trees.git.orig/block/elevator.c	2008-11-26 05:49:40.000000000 -0500
+++ linux.trees.git/block/elevator.c	2008-11-26 05:50:08.000000000 -0500
@@ -53,6 +53,9 @@ static const int elv_hash_shift = 6;
 #define rq_hash_key(rq)		((rq)->sector + (rq)->nr_sectors)
 #define ELV_ON_HASH(rq)		(!hlist_unhashed(&(rq)->hash))
 
+DEFINE_TRACE(block_rq_insert);
+DEFINE_TRACE(block_rq_issue);
+
 /*
  * Query io scheduler to see if the current process issuing bio may be
  * merged with rq.
Index: linux.trees.git/include/trace/block.h
===================================================================
--- linux.trees.git.orig/include/trace/block.h	2008-11-26 05:50:35.000000000 -0500
+++ linux.trees.git/include/trace/block.h	2008-11-26 05:51:09.000000000 -0500
@@ -4,55 +4,55 @@
 #include <linux/blkdev.h>
 #include <linux/tracepoint.h>
 
-DEFINE_TRACE(block_rq_abort,
+DECLARE_TRACE(block_rq_abort,
 	TPPROTO(struct request_queue *q, struct request *rq),
 	TPARGS(q, rq));
-DEFINE_TRACE(block_rq_insert,
+DECLARE_TRACE(block_rq_insert,
 	TPPROTO(struct request_queue *q, struct request *rq),
 	TPARGS(q, rq));
-DEFINE_TRACE(block_rq_issue,
+DECLARE_TRACE(block_rq_issue,
 	TPPROTO(struct request_queue *q, struct request *rq),
 	TPARGS(q, rq));
-DEFINE_TRACE(block_rq_requeue,
+DECLARE_TRACE(block_rq_requeue,
 	TPPROTO(struct request_queue *q, struct request *rq),
 	TPARGS(q, rq));
-DEFINE_TRACE(block_rq_complete,
+DECLARE_TRACE(block_rq_complete,
 	TPPROTO(struct request_queue *q, struct request *rq),
 	TPARGS(q, rq));
-DEFINE_TRACE(block_bio_bounce,
+DECLARE_TRACE(block_bio_bounce,
 	TPPROTO(struct request_queue *q, struct bio *bio),
 	TPARGS(q, bio));
-DEFINE_TRACE(block_bio_complete,
+DECLARE_TRACE(block_bio_complete,
 	TPPROTO(struct request_queue *q, struct bio *bio),
 	TPARGS(q, bio));
-DEFINE_TRACE(block_bio_backmerge,
+DECLARE_TRACE(block_bio_backmerge,
 	TPPROTO(struct request_queue *q, struct bio *bio),
 	TPARGS(q, bio));
-DEFINE_TRACE(block_bio_frontmerge,
+DECLARE_TRACE(block_bio_frontmerge,
 	TPPROTO(struct request_queue *q, struct bio *bio),
 	TPARGS(q, bio));
-DEFINE_TRACE(block_bio_queue,
+DECLARE_TRACE(block_bio_queue,
 	TPPROTO(struct request_queue *q, struct bio *bio),
 	TPARGS(q, bio));
-DEFINE_TRACE(block_getrq,
+DECLARE_TRACE(block_getrq,
 	TPPROTO(struct request_queue *q, struct bio *bio, int rw),
 	TPARGS(q, bio, rw));
-DEFINE_TRACE(block_sleeprq,
+DECLARE_TRACE(block_sleeprq,
 	TPPROTO(struct request_queue *q, struct bio *bio, int rw),
 	TPARGS(q, bio, rw));
-DEFINE_TRACE(block_plug,
+DECLARE_TRACE(block_plug,
 	TPPROTO(struct request_queue *q),
 	TPARGS(q));
-DEFINE_TRACE(block_unplug_timer,
+DECLARE_TRACE(block_unplug_timer,
 	TPPROTO(struct request_queue *q),
 	TPARGS(q));
-DEFINE_TRACE(block_unplug_io,
+DECLARE_TRACE(block_unplug_io,
 	TPPROTO(struct request_queue *q),
 	TPARGS(q));
-DEFINE_TRACE(block_split,
+DECLARE_TRACE(block_split,
 	TPPROTO(struct request_queue *q, struct bio *bio, unsigned int pdu),
 	TPARGS(q, bio, pdu));
-DEFINE_TRACE(block_remap,
+DECLARE_TRACE(block_remap,
 	TPPROTO(struct request_queue *q, struct bio *bio, dev_t dev,
 		sector_t from, sector_t to),
 	TPARGS(q, bio, dev, from, to));

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

^ permalink raw reply

* Re: [PATCH] Blktrace : conversion to tracepoint define
From: Mathieu Desnoyers @ 2008-11-26 11:56 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Jens Axboe, Stephen Rothwell, linux-next,
	Arnaldo Carvalho de Melo
In-Reply-To: <20081126113727.GA25861@elte.hu>

* Ingo Molnar (mingo@elte.hu) wrote:
> 
> * Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> 
> > +DECLARE_TRACE(block_rq_abort,
> 
> btw., you forgot to define this one.
> 

I seems like it comes from a delta between 2.6.27.7 and 2.6.28-rc.
Thanks for spotting it.

Mathieu

> it should all be fine in tip/tracing/blktrace.
> 
> 	Ingo

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

^ permalink raw reply

* Re: [PATCH] Blktrace : conversion to tracepoint define
From: Ingo Molnar @ 2008-11-26 11:37 UTC (permalink / raw)
  To: Mathieu Desnoyers
  Cc: Jens Axboe, Stephen Rothwell, linux-next,
	Arnaldo Carvalho de Melo
In-Reply-To: <20081126110631.GD14826@Krystal>


* Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:

> +DECLARE_TRACE(block_rq_abort,

btw., you forgot to define this one.

it should all be fine in tip/tracing/blktrace.

	Ingo

^ permalink raw reply

* Re: linux-next: block tree build failure
From: Ingo Molnar @ 2008-11-26 11:28 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Stephen Rothwell, linux-next, Mathieu Desnoyers,
	Arnaldo Carvalho de Melo
In-Reply-To: <20081126112026.GJ26308@kernel.dk>


* Jens Axboe <jens.axboe@oracle.com> wrote:

> On Wed, Nov 26 2008, Ingo Molnar wrote:
> > 
> > * Jens Axboe <jens.axboe@oracle.com> wrote:
> > 
> > > > the other direction (you merging ftrace bits) doesnt look too hot, 
> > > > you'd have to pick up:
> > > > 
> > > >    95 files changed, 5308 insertions(+), 1603 deletions(-)
> > > 
> > > Lets do that, it's just a single patch here from Arnaldo. I have 
> > > attached it to this email.
> > 
> > thanks, here's the conversion to tracepoints below. Stephen, you 
> > might want to pick up the blk tree straight away plus the fix 
> > below.
> 
> I already pruned the patch from for-next and updated it, so you 
> should not have any conflicts with or without this being merged.

ok, thanks. The next ftrace-next update will have this.

	Ingo

^ permalink raw reply

* fuse tree
From: Miklos Szeredi @ 2008-11-26 11:29 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, akpm, tj

Hi Stephen,

Could you please add the following git tree, containing fuse patches
to be included in 2.6.29, to the linux-next lineup?

git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git for-next

Thanks,
Miklos

^ permalink raw reply

* Re: [PATCH] Blktrace : conversion to tracepoint define
From: Mathieu Desnoyers @ 2008-11-26 11:27 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Jens Axboe, Stephen Rothwell, linux-next,
	Arnaldo Carvalho de Melo
In-Reply-To: <20081126112351.GA23386@elte.hu>

* Ingo Molnar (mingo@elte.hu) wrote:
> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > Moving the tracepoint definitions into blktrace.c consolidates it 
> > nicely without cluttering the various block/* files and ties their 
> > presence to CONFIG_BLK_DEV_IO_TRACE as well.
> 
> hm, the latter is not a good idea: the tracepoints will be undefined 
> when the io tracer is disabled - not good. I'll spread them out like 
> you did.
> 
> 	Ingo

Ah, yes, I thought there should be good reason for me doing things the
way I did them. ;)

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

^ permalink raw reply

* Re: linux-next: block tree build failure
From: Ingo Molnar @ 2008-11-26 11:25 UTC (permalink / raw)
  To: Mathieu Desnoyers
  Cc: Jens Axboe, Stephen Rothwell, linux-next,
	Arnaldo Carvalho de Melo
In-Reply-To: <20081126112310.GA17392@Krystal>


* Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:

> * Ingo Molnar (mingo@elte.hu) wrote:
> > 
> > * Jens Axboe <jens.axboe@oracle.com> wrote:
> > 
> > > > the other direction (you merging ftrace bits) doesnt look too hot, 
> > > > you'd have to pick up:
> > > > 
> > > >    95 files changed, 5308 insertions(+), 1603 deletions(-)
> > > 
> > > Lets do that, it's just a single patch here from Arnaldo. I have 
> > > attached it to this email.
> > 
> > thanks, here's the conversion to tracepoints below. Stephen, you might 
> > want to pick up the blk tree straight away plus the fix below.
> 
> I guess the only difference between your implementation and mine is 
> that you define all the tracepoints in block/blktrace.c, while I 
> define them in the various files where they are used. I don't feel 
> very strongly opinioned about any of the two alternatives.

usage site build attribute must be the same as definition site 
attribute. So blktrace.c is not a good place - we will fail the build 
in the !CONFIG_BLK_DEV_IO_TRACE case. I'll apply your spread-out 
definition variant.

	Ingo

^ permalink raw reply

* Re: [PATCH] Blktrace : conversion to tracepoint define
From: Ingo Molnar @ 2008-11-26 11:23 UTC (permalink / raw)
  To: Mathieu Desnoyers
  Cc: Jens Axboe, Stephen Rothwell, linux-next,
	Arnaldo Carvalho de Melo
In-Reply-To: <20081126112208.GB20601@elte.hu>


* Ingo Molnar <mingo@elte.hu> wrote:

> Moving the tracepoint definitions into blktrace.c consolidates it 
> nicely without cluttering the various block/* files and ties their 
> presence to CONFIG_BLK_DEV_IO_TRACE as well.

hm, the latter is not a good idea: the tracepoints will be undefined 
when the io tracer is disabled - not good. I'll spread them out like 
you did.

	Ingo

^ permalink raw reply

* Re: linux-next: block tree build failure
From: Mathieu Desnoyers @ 2008-11-26 11:23 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Jens Axboe, Stephen Rothwell, linux-next,
	Arnaldo Carvalho de Melo
In-Reply-To: <20081126111621.GA20601@elte.hu>

* Ingo Molnar (mingo@elte.hu) wrote:
> 
> * Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > > the other direction (you merging ftrace bits) doesnt look too hot, 
> > > you'd have to pick up:
> > > 
> > >    95 files changed, 5308 insertions(+), 1603 deletions(-)
> > 
> > Lets do that, it's just a single patch here from Arnaldo. I have 
> > attached it to this email.
> 
> thanks, here's the conversion to tracepoints below. Stephen, you might 
> want to pick up the blk tree straight away plus the fix below.
> 

I guess the only difference between your implementation and mine is that
you define all the tracepoints in block/blktrace.c, while I define them
in the various files where they are used. I don't feel very strongly
opinioned about any of the two alternatives.

Mathieu

> 	Ingo
> 
> --------------->
> From 65ae5a3c622e707dbf7630397e94b7e2e9cd0ea5 Mon Sep 17 00:00:00 2001
> From: Ingo Molnar <mingo@elte.hu>
> Date: Wed, 26 Nov 2008 11:59:56 +0100
> Subject: [PATCH] blktrace: port to tracepoints, update
> 
> Port to the new tracepoints API: split DEFINE_TRACE() and DECLARE_TRACE()
> sites.
> 
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  block/blktrace.c      |   18 ++++++++++
>  include/trace/block.h |   84 +++++++++++++++++++++++++++++--------------------
>  2 files changed, 68 insertions(+), 34 deletions(-)
> 
> diff --git a/block/blktrace.c b/block/blktrace.c
> index b0a2cae..1dba3fb 100644
> --- a/block/blktrace.c
> +++ b/block/blktrace.c
> @@ -35,6 +35,24 @@ static atomic_t blk_probes_ref = ATOMIC_INIT(0);
>  static int blk_register_tracepoints(void);
>  static void blk_unregister_tracepoints(void);
>  
> +DEFINE_TRACE(block_bio_backmerge);
> +DEFINE_TRACE(block_bio_bounce);
> +DEFINE_TRACE(block_bio_complete);
> +DEFINE_TRACE(block_bio_frontmerge);
> +DEFINE_TRACE(block_bio_queue);
> +DEFINE_TRACE(block_getrq);
> +DEFINE_TRACE(block_plug);
> +DEFINE_TRACE(block_remap);
> +DEFINE_TRACE(block_rq_abort);
> +DEFINE_TRACE(block_rq_complete);
> +DEFINE_TRACE(block_rq_insert);
> +DEFINE_TRACE(block_rq_issue);
> +DEFINE_TRACE(block_rq_requeue);
> +DEFINE_TRACE(block_sleeprq);
> +DEFINE_TRACE(block_split);
> +DEFINE_TRACE(block_unplug_io);
> +DEFINE_TRACE(block_unplug_timer);
> +
>  /*
>   * Send out a notify message.
>   */
> diff --git a/include/trace/block.h b/include/trace/block.h
> index 3cc2675..25c6a1f 100644
> --- a/include/trace/block.h
> +++ b/include/trace/block.h
> @@ -4,57 +4,73 @@
>  #include <linux/blkdev.h>
>  #include <linux/tracepoint.h>
>  
> -DEFINE_TRACE(block_rq_abort,
> +DECLARE_TRACE(block_rq_abort,
>  	TPPROTO(struct request_queue *q, struct request *rq),
> -	TPARGS(q, rq));
> -DEFINE_TRACE(block_rq_insert,
> +		TPARGS(q, rq));
> +
> +DECLARE_TRACE(block_rq_insert,
>  	TPPROTO(struct request_queue *q, struct request *rq),
> -	TPARGS(q, rq));
> -DEFINE_TRACE(block_rq_issue,
> +		TPARGS(q, rq));
> +
> +DECLARE_TRACE(block_rq_issue,
>  	TPPROTO(struct request_queue *q, struct request *rq),
> -	TPARGS(q, rq));
> -DEFINE_TRACE(block_rq_requeue,
> +		TPARGS(q, rq));
> +
> +DECLARE_TRACE(block_rq_requeue,
>  	TPPROTO(struct request_queue *q, struct request *rq),
> -	TPARGS(q, rq));
> -DEFINE_TRACE(block_rq_complete,
> +		TPARGS(q, rq));
> +
> +DECLARE_TRACE(block_rq_complete,
>  	TPPROTO(struct request_queue *q, struct request *rq),
> -	TPARGS(q, rq));
> -DEFINE_TRACE(block_bio_bounce,
> +		TPARGS(q, rq));
> +
> +DECLARE_TRACE(block_bio_bounce,
>  	TPPROTO(struct request_queue *q, struct bio *bio),
> -	TPARGS(q, bio));
> -DEFINE_TRACE(block_bio_complete,
> +		TPARGS(q, bio));
> +
> +DECLARE_TRACE(block_bio_complete,
>  	TPPROTO(struct request_queue *q, struct bio *bio),
> -	TPARGS(q, bio));
> -DEFINE_TRACE(block_bio_backmerge,
> +		TPARGS(q, bio));
> +
> +DECLARE_TRACE(block_bio_backmerge,
>  	TPPROTO(struct request_queue *q, struct bio *bio),
> -	TPARGS(q, bio));
> -DEFINE_TRACE(block_bio_frontmerge,
> +		TPARGS(q, bio));
> +
> +DECLARE_TRACE(block_bio_frontmerge,
>  	TPPROTO(struct request_queue *q, struct bio *bio),
> -	TPARGS(q, bio));
> -DEFINE_TRACE(block_bio_queue,
> +		TPARGS(q, bio));
> +
> +DECLARE_TRACE(block_bio_queue,
>  	TPPROTO(struct request_queue *q, struct bio *bio),
> -	TPARGS(q, bio));
> -DEFINE_TRACE(block_getrq,
> +		TPARGS(q, bio));
> +
> +DECLARE_TRACE(block_getrq,
>  	TPPROTO(struct request_queue *q, struct bio *bio, int rw),
> -	TPARGS(q, bio, rw));
> -DEFINE_TRACE(block_sleeprq,
> +		TPARGS(q, bio, rw));
> +
> +DECLARE_TRACE(block_sleeprq,
>  	TPPROTO(struct request_queue *q, struct bio *bio, int rw),
> -	TPARGS(q, bio, rw));
> -DEFINE_TRACE(block_plug,
> +		TPARGS(q, bio, rw));
> +
> +DECLARE_TRACE(block_plug,
>  	TPPROTO(struct request_queue *q),
> -	TPARGS(q));
> -DEFINE_TRACE(block_unplug_timer,
> +		TPARGS(q));
> +
> +DECLARE_TRACE(block_unplug_timer,
>  	TPPROTO(struct request_queue *q),
> -	TPARGS(q));
> -DEFINE_TRACE(block_unplug_io,
> +		TPARGS(q));
> +
> +DECLARE_TRACE(block_unplug_io,
>  	TPPROTO(struct request_queue *q),
> -	TPARGS(q));
> -DEFINE_TRACE(block_split,
> +		TPARGS(q));
> +
> +DECLARE_TRACE(block_split,
>  	TPPROTO(struct request_queue *q, struct bio *bio, unsigned int pdu),
> -	TPARGS(q, bio, pdu));
> -DEFINE_TRACE(block_remap,
> +		TPARGS(q, bio, pdu));
> +
> +DECLARE_TRACE(block_remap,
>  	TPPROTO(struct request_queue *q, struct bio *bio, dev_t dev,
>  		sector_t from, sector_t to),
> -	TPARGS(q, bio, dev, from, to));
> +		TPARGS(q, bio, dev, from, to));
>  
>  #endif

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

^ permalink raw reply

* Re: [PATCH] Blktrace : conversion to tracepoint define
From: Ingo Molnar @ 2008-11-26 11:22 UTC (permalink / raw)
  To: Mathieu Desnoyers
  Cc: Jens Axboe, Stephen Rothwell, linux-next,
	Arnaldo Carvalho de Melo
In-Reply-To: <20081126110631.GD14826@Krystal>


* Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:

> Here is the conversion to the new tracepoint API, which applies to 
> -tip after the patch you just emailed.
> 
> Mathieu
> 
> 
> Blktrace : conversion to tracepoint define
> 
> Adapt declaration/definitions of blktrace tracepoints to the new 
> tracepoint API.
> 
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> CC: Arnaldo Carvalho de Melo <acme@redhat.com>
> CC: 'Ingo Molnar' <mingo@elte.hu>
> CC: Jens Axboe <jens.axboe@oracle.com>
> CC: Arnaldo Carvalho de Melo <acme@redhat.com>
> CC: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  block/blk-core.c      |   13 +++++++++++++
>  block/elevator.c      |    3 +++
>  drivers/md/dm.c       |    2 ++
>  fs/bio.c              |    2 ++
>  include/trace/block.h |   34 +++++++++++++++++-----------------
>  mm/bounce.c           |    2 ++
>  6 files changed, 39 insertions(+), 17 deletions(-)
> 
> Index: linux.trees.git/mm/bounce.c
> ===================================================================
> --- linux.trees.git.orig/mm/bounce.c	2008-11-26 05:49:40.000000000 -0500
> +++ linux.trees.git/mm/bounce.c	2008-11-26 05:50:08.000000000 -0500
> @@ -22,6 +22,8 @@
>  
>  static mempool_t *page_pool, *isa_page_pool;
>  
> +DEFINE_TRACE(block_bio_bounce);
> +

>  #ifdef CONFIG_HIGHMEM
>  static __init int init_emergency_pool(void)
>  {
> Index: linux.trees.git/fs/bio.c
> ===================================================================
> --- linux.trees.git.orig/fs/bio.c	2008-11-26 05:49:40.000000000 -0500
> +++ linux.trees.git/fs/bio.c	2008-11-26 05:50:25.000000000 -0500
> @@ -29,6 +29,8 @@
>  #include <trace/block.h>
>  #include <scsi/sg.h>		/* for struct sg_iovec */
>  
> +DEFINE_TRACE(block_split);
> +
>  static struct kmem_cache *bio_slab __read_mostly;

heh, just did a similar patch :)

i moved the tracepoint definitions into a central place in 
block/blktrace.c, not spread out in the block files - because some of 
the tracepoints such as trace_block_remap() get used from multiple 
places so there's no real "home" file for them.

Moving the tracepoint definitions into blktrace.c consolidates it 
nicely without cluttering the various block/* files and ties their 
presence to CONFIG_BLK_DEV_IO_TRACE as well.

	Ingo

^ permalink raw reply

* Re: linux-next: block tree build failure
From: Jens Axboe @ 2008-11-26 11:20 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, linux-next, Mathieu Desnoyers,
	Arnaldo Carvalho de Melo
In-Reply-To: <20081126111621.GA20601@elte.hu>

On Wed, Nov 26 2008, Ingo Molnar wrote:
> 
> * Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > > the other direction (you merging ftrace bits) doesnt look too hot, 
> > > you'd have to pick up:
> > > 
> > >    95 files changed, 5308 insertions(+), 1603 deletions(-)
> > 
> > Lets do that, it's just a single patch here from Arnaldo. I have 
> > attached it to this email.
> 
> thanks, here's the conversion to tracepoints below. Stephen, you might 
> want to pick up the blk tree straight away plus the fix below.

I already pruned the patch from for-next and updated it, so you should
not have any conflicts with or without this being merged.


-- 
Jens Axboe

^ permalink raw reply

* Re: linux-next: block tree build failure
From: Ingo Molnar @ 2008-11-26 11:16 UTC (permalink / raw)
  To: Jens Axboe
  Cc: Stephen Rothwell, linux-next, Mathieu Desnoyers,
	Arnaldo Carvalho de Melo
In-Reply-To: <20081126104700.GI26308@kernel.dk>


* Jens Axboe <jens.axboe@oracle.com> wrote:

> > the other direction (you merging ftrace bits) doesnt look too hot, 
> > you'd have to pick up:
> > 
> >    95 files changed, 5308 insertions(+), 1603 deletions(-)
> 
> Lets do that, it's just a single patch here from Arnaldo. I have 
> attached it to this email.

thanks, here's the conversion to tracepoints below. Stephen, you might 
want to pick up the blk tree straight away plus the fix below.

	Ingo

--------------->
>From 65ae5a3c622e707dbf7630397e94b7e2e9cd0ea5 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Wed, 26 Nov 2008 11:59:56 +0100
Subject: [PATCH] blktrace: port to tracepoints, update

Port to the new tracepoints API: split DEFINE_TRACE() and DECLARE_TRACE()
sites.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 block/blktrace.c      |   18 ++++++++++
 include/trace/block.h |   84 +++++++++++++++++++++++++++++--------------------
 2 files changed, 68 insertions(+), 34 deletions(-)

diff --git a/block/blktrace.c b/block/blktrace.c
index b0a2cae..1dba3fb 100644
--- a/block/blktrace.c
+++ b/block/blktrace.c
@@ -35,6 +35,24 @@ static atomic_t blk_probes_ref = ATOMIC_INIT(0);
 static int blk_register_tracepoints(void);
 static void blk_unregister_tracepoints(void);
 
+DEFINE_TRACE(block_bio_backmerge);
+DEFINE_TRACE(block_bio_bounce);
+DEFINE_TRACE(block_bio_complete);
+DEFINE_TRACE(block_bio_frontmerge);
+DEFINE_TRACE(block_bio_queue);
+DEFINE_TRACE(block_getrq);
+DEFINE_TRACE(block_plug);
+DEFINE_TRACE(block_remap);
+DEFINE_TRACE(block_rq_abort);
+DEFINE_TRACE(block_rq_complete);
+DEFINE_TRACE(block_rq_insert);
+DEFINE_TRACE(block_rq_issue);
+DEFINE_TRACE(block_rq_requeue);
+DEFINE_TRACE(block_sleeprq);
+DEFINE_TRACE(block_split);
+DEFINE_TRACE(block_unplug_io);
+DEFINE_TRACE(block_unplug_timer);
+
 /*
  * Send out a notify message.
  */
diff --git a/include/trace/block.h b/include/trace/block.h
index 3cc2675..25c6a1f 100644
--- a/include/trace/block.h
+++ b/include/trace/block.h
@@ -4,57 +4,73 @@
 #include <linux/blkdev.h>
 #include <linux/tracepoint.h>
 
-DEFINE_TRACE(block_rq_abort,
+DECLARE_TRACE(block_rq_abort,
 	TPPROTO(struct request_queue *q, struct request *rq),
-	TPARGS(q, rq));
-DEFINE_TRACE(block_rq_insert,
+		TPARGS(q, rq));
+
+DECLARE_TRACE(block_rq_insert,
 	TPPROTO(struct request_queue *q, struct request *rq),
-	TPARGS(q, rq));
-DEFINE_TRACE(block_rq_issue,
+		TPARGS(q, rq));
+
+DECLARE_TRACE(block_rq_issue,
 	TPPROTO(struct request_queue *q, struct request *rq),
-	TPARGS(q, rq));
-DEFINE_TRACE(block_rq_requeue,
+		TPARGS(q, rq));
+
+DECLARE_TRACE(block_rq_requeue,
 	TPPROTO(struct request_queue *q, struct request *rq),
-	TPARGS(q, rq));
-DEFINE_TRACE(block_rq_complete,
+		TPARGS(q, rq));
+
+DECLARE_TRACE(block_rq_complete,
 	TPPROTO(struct request_queue *q, struct request *rq),
-	TPARGS(q, rq));
-DEFINE_TRACE(block_bio_bounce,
+		TPARGS(q, rq));
+
+DECLARE_TRACE(block_bio_bounce,
 	TPPROTO(struct request_queue *q, struct bio *bio),
-	TPARGS(q, bio));
-DEFINE_TRACE(block_bio_complete,
+		TPARGS(q, bio));
+
+DECLARE_TRACE(block_bio_complete,
 	TPPROTO(struct request_queue *q, struct bio *bio),
-	TPARGS(q, bio));
-DEFINE_TRACE(block_bio_backmerge,
+		TPARGS(q, bio));
+
+DECLARE_TRACE(block_bio_backmerge,
 	TPPROTO(struct request_queue *q, struct bio *bio),
-	TPARGS(q, bio));
-DEFINE_TRACE(block_bio_frontmerge,
+		TPARGS(q, bio));
+
+DECLARE_TRACE(block_bio_frontmerge,
 	TPPROTO(struct request_queue *q, struct bio *bio),
-	TPARGS(q, bio));
-DEFINE_TRACE(block_bio_queue,
+		TPARGS(q, bio));
+
+DECLARE_TRACE(block_bio_queue,
 	TPPROTO(struct request_queue *q, struct bio *bio),
-	TPARGS(q, bio));
-DEFINE_TRACE(block_getrq,
+		TPARGS(q, bio));
+
+DECLARE_TRACE(block_getrq,
 	TPPROTO(struct request_queue *q, struct bio *bio, int rw),
-	TPARGS(q, bio, rw));
-DEFINE_TRACE(block_sleeprq,
+		TPARGS(q, bio, rw));
+
+DECLARE_TRACE(block_sleeprq,
 	TPPROTO(struct request_queue *q, struct bio *bio, int rw),
-	TPARGS(q, bio, rw));
-DEFINE_TRACE(block_plug,
+		TPARGS(q, bio, rw));
+
+DECLARE_TRACE(block_plug,
 	TPPROTO(struct request_queue *q),
-	TPARGS(q));
-DEFINE_TRACE(block_unplug_timer,
+		TPARGS(q));
+
+DECLARE_TRACE(block_unplug_timer,
 	TPPROTO(struct request_queue *q),
-	TPARGS(q));
-DEFINE_TRACE(block_unplug_io,
+		TPARGS(q));
+
+DECLARE_TRACE(block_unplug_io,
 	TPPROTO(struct request_queue *q),
-	TPARGS(q));
-DEFINE_TRACE(block_split,
+		TPARGS(q));
+
+DECLARE_TRACE(block_split,
 	TPPROTO(struct request_queue *q, struct bio *bio, unsigned int pdu),
-	TPARGS(q, bio, pdu));
-DEFINE_TRACE(block_remap,
+		TPARGS(q, bio, pdu));
+
+DECLARE_TRACE(block_remap,
 	TPPROTO(struct request_queue *q, struct bio *bio, dev_t dev,
 		sector_t from, sector_t to),
-	TPARGS(q, bio, dev, from, to));
+		TPARGS(q, bio, dev, from, to));
 
 #endif

^ permalink raw reply related

* Re: linux-next: block tree build failure
From: Jens Axboe @ 2008-11-26 10:47 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, linux-next, Mathieu Desnoyers,
	Arnaldo Carvalho de Melo
In-Reply-To: <20081126104259.GB6052@elte.hu>

[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]

On Wed, Nov 26 2008, Ingo Molnar wrote:
> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi Jens,
> > 
> > Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> > 
> > In file included from block/blk-core.c:31:
> > include/trace/block.h:9:15: error: macro "DEFINE_TRACE" passed 3 arguments, but takes just 1
> > In file included from block/blk-core.c:31:
> > include/trace/block.h:7: warning: data definition has no type or storage class
> > include/trace/block.h:7: warning: type defaults to 'int' in declaration of 'DEFINE_TRACE'
> > 
> > and many more.  This is caused by commit 
> > 714d010b5c249c2e9282515e0a2309a61ababbf4 ("blktrace: port to 
> > tracepoints") interacting with commit 
> > 7e066fb870fcd1025ec3ba7bbde5d541094f4ce1 ("tracepoints: add 
> > DECLARE_TRACE () and DEFINE_TRACE()") which entered linux-next for 
> > the first time today via the ftrace tree. This latter commit has 
> > changed the tracepoints API.
> > 
> > I will drop the block tree for today.  I am not sure of the way forward.
> 
> hm, i think that might be interaction between ftrace tree updates and 
> blktrace?
> 
> Jens, would it be fine with you if we created a new 
> tip/tracing/blktrace branch and picked up your changes and kept it all 
> uptodate and merged with the ftrace tree? It should merge fine with 
> other bits of the block tree, right? (the tracepoints are in rather 
> stable spots of the code i think)
> 
> the other direction (you merging ftrace bits) doesnt look too hot, 
> you'd have to pick up:
> 
>    95 files changed, 5308 insertions(+), 1603 deletions(-)

Lets do that, it's just a single patch here from Arnaldo. I have
attached it to this email.

-- 
Jens Axboe


[-- Attachment #2: 0001-blktrace-port-to-tracepoints.patch --]
[-- Type: text/x-patch, Size: 28109 bytes --]

>From 714d010b5c249c2e9282515e0a2309a61ababbf4 Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Thu, 30 Oct 2008 08:34:33 +0100
Subject: [PATCH] blktrace: port to tracepoints

This was a forward port of work done by Mathieu Desnoyers, I changed it to
encode the 'what' parameter on the tracepoint name, so that one can register
interest in specific events and not on classes of events to then check the
'what' parameter.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
---
 block/Kconfig                |    1 +
 block/blk-core.c             |   33 ++---
 block/blktrace.c             |  332 +++++++++++++++++++++++++++++++++++++++++-
 block/elevator.c             |    7 +-
 drivers/md/dm.c              |    6 +-
 fs/bio.c                     |    3 +-
 include/linux/blktrace_api.h |  172 +---------------------
 include/trace/block.h        |   60 ++++++++
 mm/bounce.c                  |    3 +-
 9 files changed, 418 insertions(+), 199 deletions(-)
 create mode 100644 include/trace/block.h

diff --git a/block/Kconfig b/block/Kconfig
index 1ab7c15..290b219 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -47,6 +47,7 @@ config BLK_DEV_IO_TRACE
 	depends on SYSFS
 	select RELAY
 	select DEBUG_FS
+	select TRACEPOINTS
 	help
 	  Say Y here if you want to be able to trace the block layer actions
 	  on a given queue. Tracing allows you to see any traffic happening
diff --git a/block/blk-core.c b/block/blk-core.c
index 10e8a64..04267d6 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -28,6 +28,7 @@
 #include <linux/task_io_accounting_ops.h>
 #include <linux/blktrace_api.h>
 #include <linux/fault-inject.h>
+#include <trace/block.h>
 
 #include "blk.h"
 
@@ -205,7 +206,7 @@ void blk_plug_device(struct request_queue *q)
 
 	if (!queue_flag_test_and_set(QUEUE_FLAG_PLUGGED, q)) {
 		mod_timer(&q->unplug_timer, jiffies + q->unplug_delay);
-		blk_add_trace_generic(q, NULL, 0, BLK_TA_PLUG);
+		trace_block_plug(q);
 	}
 }
 EXPORT_SYMBOL(blk_plug_device);
@@ -292,9 +293,7 @@ void blk_unplug_work(struct work_struct *work)
 	struct request_queue *q =
 		container_of(work, struct request_queue, unplug_work);
 
-	blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_IO, NULL,
-				q->rq.count[READ] + q->rq.count[WRITE]);
-
+	trace_block_unplug_io(q);
 	q->unplug_fn(q);
 }
 
@@ -302,9 +301,7 @@ void blk_unplug_timeout(unsigned long data)
 {
 	struct request_queue *q = (struct request_queue *)data;
 
-	blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_TIMER, NULL,
-				q->rq.count[READ] + q->rq.count[WRITE]);
-
+	trace_block_unplug_timer(q);
 	kblockd_schedule_work(q, &q->unplug_work);
 }
 
@@ -314,9 +311,7 @@ void blk_unplug(struct request_queue *q)
 	 * devices don't necessarily have an ->unplug_fn defined
 	 */
 	if (q->unplug_fn) {
-		blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_IO, NULL,
-					q->rq.count[READ] + q->rq.count[WRITE]);
-
+		trace_block_unplug_io(q);
 		q->unplug_fn(q);
 	}
 }
@@ -822,7 +817,7 @@ rq_starved:
 	if (ioc_batching(q, ioc))
 		ioc->nr_batch_requests--;
 
-	blk_add_trace_generic(q, bio, rw, BLK_TA_GETRQ);
+	trace_block_getrq(q, bio, rw);
 out:
 	return rq;
 }
@@ -848,7 +843,7 @@ static struct request *get_request_wait(struct request_queue *q, int rw_flags,
 		prepare_to_wait_exclusive(&rl->wait[rw], &wait,
 				TASK_UNINTERRUPTIBLE);
 
-		blk_add_trace_generic(q, bio, rw, BLK_TA_SLEEPRQ);
+		trace_block_sleeprq(q, bio, rw);
 
 		__generic_unplug_device(q);
 		spin_unlock_irq(q->queue_lock);
@@ -928,7 +923,7 @@ void blk_requeue_request(struct request_queue *q, struct request *rq)
 {
 	blk_delete_timer(rq);
 	blk_clear_rq_complete(rq);
-	blk_add_trace_rq(q, rq, BLK_TA_REQUEUE);
+	trace_block_rq_requeue(q, rq);
 
 	if (blk_rq_tagged(rq))
 		blk_queue_end_tag(q, rq);
@@ -1167,7 +1162,7 @@ static int __make_request(struct request_queue *q, struct bio *bio)
 		if (!ll_back_merge_fn(q, req, bio))
 			break;
 
-		blk_add_trace_bio(q, bio, BLK_TA_BACKMERGE);
+		trace_block_bio_backmerge(q, bio);
 
 		req->biotail->bi_next = bio;
 		req->biotail = bio;
@@ -1186,7 +1181,7 @@ static int __make_request(struct request_queue *q, struct bio *bio)
 		if (!ll_front_merge_fn(q, req, bio))
 			break;
 
-		blk_add_trace_bio(q, bio, BLK_TA_FRONTMERGE);
+		trace_block_bio_frontmerge(q, bio);
 
 		bio->bi_next = req->bio;
 		req->bio = bio;
@@ -1269,7 +1264,7 @@ static inline void blk_partition_remap(struct bio *bio)
 		bio->bi_sector += p->start_sect;
 		bio->bi_bdev = bdev->bd_contains;
 
-		blk_add_trace_remap(bdev_get_queue(bio->bi_bdev), bio,
+		trace_block_remap(bdev_get_queue(bio->bi_bdev), bio,
 				    bdev->bd_dev, bio->bi_sector,
 				    bio->bi_sector - p->start_sect);
 	}
@@ -1441,10 +1436,10 @@ end_io:
 			goto end_io;
 
 		if (old_sector != -1)
-			blk_add_trace_remap(q, bio, old_dev, bio->bi_sector,
+			trace_block_remap(q, bio, old_dev, bio->bi_sector,
 					    old_sector);
 
-		blk_add_trace_bio(q, bio, BLK_TA_QUEUE);
+		trace_block_bio_queue(q, bio);
 
 		old_sector = bio->bi_sector;
 		old_dev = bio->bi_bdev->bd_dev;
@@ -1656,7 +1651,7 @@ static int __end_that_request_first(struct request *req, int error,
 	int total_bytes, bio_nbytes, next_idx = 0;
 	struct bio *bio;
 
-	blk_add_trace_rq(req->q, req, BLK_TA_COMPLETE);
+	trace_block_rq_complete(req->q, req);
 
 	/*
 	 * for a REQ_TYPE_BLOCK_PC request, we want to carry any eventual
diff --git a/block/blktrace.c b/block/blktrace.c
index 85049a7..b0a2cae 100644
--- a/block/blktrace.c
+++ b/block/blktrace.c
@@ -23,10 +23,18 @@
 #include <linux/mutex.h>
 #include <linux/debugfs.h>
 #include <linux/time.h>
+#include <trace/block.h>
 #include <asm/uaccess.h>
 
 static unsigned int blktrace_seq __read_mostly = 1;
 
+/* Global reference count of probes */
+static DEFINE_MUTEX(blk_probe_mutex);
+static atomic_t blk_probes_ref = ATOMIC_INIT(0);
+
+static int blk_register_tracepoints(void);
+static void blk_unregister_tracepoints(void);
+
 /*
  * Send out a notify message.
  */
@@ -119,7 +127,7 @@ static u32 ddir_act[2] __read_mostly = { BLK_TC_ACT(BLK_TC_READ), BLK_TC_ACT(BLK
  * The worker for the various blk_add_trace*() types. Fills out a
  * blk_io_trace structure and places it in a per-cpu subbuffer.
  */
-void __blk_add_trace(struct blk_trace *bt, sector_t sector, int bytes,
+static void __blk_add_trace(struct blk_trace *bt, sector_t sector, int bytes,
 		     int rw, u32 what, int error, int pdu_len, void *pdu_data)
 {
 	struct task_struct *tsk = current;
@@ -177,8 +185,6 @@ void __blk_add_trace(struct blk_trace *bt, sector_t sector, int bytes,
 	local_irq_restore(flags);
 }
 
-EXPORT_SYMBOL_GPL(__blk_add_trace);
-
 static struct dentry *blk_tree_root;
 static DEFINE_MUTEX(blk_tree_mutex);
 static unsigned int root_users;
@@ -237,6 +243,10 @@ static void blk_trace_cleanup(struct blk_trace *bt)
 	free_percpu(bt->sequence);
 	free_percpu(bt->msg_data);
 	kfree(bt);
+	mutex_lock(&blk_probe_mutex);
+	if (atomic_dec_and_test(&blk_probes_ref))
+		blk_unregister_tracepoints();
+	mutex_unlock(&blk_probe_mutex);
 }
 
 int blk_trace_remove(struct request_queue *q)
@@ -428,6 +438,14 @@ int do_blk_trace_setup(struct request_queue *q, char *name, dev_t dev,
 	bt->pid = buts->pid;
 	bt->trace_state = Blktrace_setup;
 
+	mutex_lock(&blk_probe_mutex);
+	if (atomic_add_return(1, &blk_probes_ref) == 1) {
+		ret = blk_register_tracepoints();
+		if (ret)
+			goto probe_err;
+	}
+	mutex_unlock(&blk_probe_mutex);
+
 	ret = -EBUSY;
 	old_bt = xchg(&q->blk_trace, bt);
 	if (old_bt) {
@@ -436,6 +454,9 @@ int do_blk_trace_setup(struct request_queue *q, char *name, dev_t dev,
 	}
 
 	return 0;
+probe_err:
+	atomic_dec(&blk_probes_ref);
+	mutex_unlock(&blk_probe_mutex);
 err:
 	if (dir)
 		blk_remove_tree(dir);
@@ -562,3 +583,308 @@ void blk_trace_shutdown(struct request_queue *q)
 		blk_trace_remove(q);
 	}
 }
+
+/*
+ * blktrace probes
+ */
+
+/**
+ * blk_add_trace_rq - Add a trace for a request oriented action
+ * @q:		queue the io is for
+ * @rq:		the source request
+ * @what:	the action
+ *
+ * Description:
+ *     Records an action against a request. Will log the bio offset + size.
+ *
+ **/
+static void blk_add_trace_rq(struct request_queue *q, struct request *rq,
+				    u32 what)
+{
+	struct blk_trace *bt = q->blk_trace;
+	int rw = rq->cmd_flags & 0x03;
+
+	if (likely(!bt))
+		return;
+
+	if (blk_discard_rq(rq))
+		rw |= (1 << BIO_RW_DISCARD);
+
+	if (blk_pc_request(rq)) {
+		what |= BLK_TC_ACT(BLK_TC_PC);
+		__blk_add_trace(bt, 0, rq->data_len, rw, what, rq->errors,
+				sizeof(rq->cmd), rq->cmd);
+	} else  {
+		what |= BLK_TC_ACT(BLK_TC_FS);
+		__blk_add_trace(bt, rq->hard_sector, rq->hard_nr_sectors << 9,
+				rw, what, rq->errors, 0, NULL);
+	}
+}
+
+static void blk_add_trace_rq_abort(struct request_queue *q, struct request *rq)
+{
+	blk_add_trace_rq(q, rq, BLK_TA_ABORT);
+}
+
+static void blk_add_trace_rq_insert(struct request_queue *q, struct request *rq)
+{
+	blk_add_trace_rq(q, rq, BLK_TA_INSERT);
+}
+
+static void blk_add_trace_rq_issue(struct request_queue *q, struct request *rq)
+{
+	blk_add_trace_rq(q, rq, BLK_TA_ISSUE);
+}
+
+static void blk_add_trace_rq_requeue(struct request_queue *q, struct request *rq)
+{
+	blk_add_trace_rq(q, rq, BLK_TA_REQUEUE);
+}
+
+static void blk_add_trace_rq_complete(struct request_queue *q, struct request *rq)
+{
+	blk_add_trace_rq(q, rq, BLK_TA_COMPLETE);
+}
+
+/**
+ * blk_add_trace_bio - Add a trace for a bio oriented action
+ * @q:		queue the io is for
+ * @bio:	the source bio
+ * @what:	the action
+ *
+ * Description:
+ *     Records an action against a bio. Will log the bio offset + size.
+ *
+ **/
+static void blk_add_trace_bio(struct request_queue *q, struct bio *bio,
+				     u32 what)
+{
+	struct blk_trace *bt = q->blk_trace;
+
+	if (likely(!bt))
+		return;
+
+	__blk_add_trace(bt, bio->bi_sector, bio->bi_size, bio->bi_rw, what,
+			!bio_flagged(bio, BIO_UPTODATE), 0, NULL);
+}
+
+static void blk_add_trace_bio_bounce(struct request_queue *q, struct bio *bio)
+{
+	blk_add_trace_bio(q, bio, BLK_TA_BOUNCE);
+}
+
+static void blk_add_trace_bio_complete(struct request_queue *q, struct bio *bio)
+{
+	blk_add_trace_bio(q, bio, BLK_TA_COMPLETE);
+}
+
+static void blk_add_trace_bio_backmerge(struct request_queue *q, struct bio *bio)
+{
+	blk_add_trace_bio(q, bio, BLK_TA_BACKMERGE);
+}
+
+static void blk_add_trace_bio_frontmerge(struct request_queue *q, struct bio *bio)
+{
+	blk_add_trace_bio(q, bio, BLK_TA_FRONTMERGE);
+}
+
+static void blk_add_trace_bio_queue(struct request_queue *q, struct bio *bio)
+{
+	blk_add_trace_bio(q, bio, BLK_TA_QUEUE);
+}
+
+static void blk_add_trace_getrq(struct request_queue *q, struct bio *bio, int rw)
+{
+	if (bio)
+		blk_add_trace_bio(q, bio, BLK_TA_GETRQ);
+	else {
+		struct blk_trace *bt = q->blk_trace;
+
+		if (bt)
+			__blk_add_trace(bt, 0, 0, rw, BLK_TA_GETRQ, 0, 0, NULL);
+	}
+}
+
+
+static void blk_add_trace_sleeprq(struct request_queue *q, struct bio *bio, int rw)
+{
+	if (bio)
+		blk_add_trace_bio(q, bio, BLK_TA_SLEEPRQ);
+	else {
+		struct blk_trace *bt = q->blk_trace;
+
+		if (bt)
+			__blk_add_trace(bt, 0, 0, rw, BLK_TA_SLEEPRQ, 0, 0, NULL);
+	}
+}
+
+static void blk_add_trace_plug(struct request_queue *q)
+{
+	struct blk_trace *bt = q->blk_trace;
+
+	if (bt)
+		__blk_add_trace(bt, 0, 0, 0, BLK_TA_PLUG, 0, 0, NULL);
+}
+
+static void blk_add_trace_unplug_io(struct request_queue *q)
+{
+	struct blk_trace *bt = q->blk_trace;
+
+	if (bt) {
+		unsigned int pdu = q->rq.count[READ] + q->rq.count[WRITE];
+		__be64 rpdu = cpu_to_be64(pdu);
+
+		__blk_add_trace(bt, 0, 0, 0, BLK_TA_UNPLUG_IO, 0,
+				sizeof(rpdu), &rpdu);
+	}
+}
+
+static void blk_add_trace_unplug_timer(struct request_queue *q)
+{
+	struct blk_trace *bt = q->blk_trace;
+
+	if (bt) {
+		unsigned int pdu = q->rq.count[READ] + q->rq.count[WRITE];
+		__be64 rpdu = cpu_to_be64(pdu);
+
+		__blk_add_trace(bt, 0, 0, 0, BLK_TA_UNPLUG_TIMER, 0,
+				sizeof(rpdu), &rpdu);
+	}
+}
+
+static void blk_add_trace_split(struct request_queue *q, struct bio *bio,
+				unsigned int pdu)
+{
+	struct blk_trace *bt = q->blk_trace;
+
+	if (bt) {
+		__be64 rpdu = cpu_to_be64(pdu);
+
+		__blk_add_trace(bt, bio->bi_sector, bio->bi_size, bio->bi_rw,
+				BLK_TA_SPLIT, !bio_flagged(bio, BIO_UPTODATE),
+				sizeof(rpdu), &rpdu);
+	}
+}
+
+/**
+ * blk_add_trace_remap - Add a trace for a remap operation
+ * @q:		queue the io is for
+ * @bio:	the source bio
+ * @dev:	target device
+ * @from:	source sector
+ * @to:		target sector
+ *
+ * Description:
+ *     Device mapper or raid target sometimes need to split a bio because
+ *     it spans a stripe (or similar). Add a trace for that action.
+ *
+ **/
+static void blk_add_trace_remap(struct request_queue *q, struct bio *bio,
+				       dev_t dev, sector_t from, sector_t to)
+{
+	struct blk_trace *bt = q->blk_trace;
+	struct blk_io_trace_remap r;
+
+	if (likely(!bt))
+		return;
+
+	r.device = cpu_to_be32(dev);
+	r.device_from = cpu_to_be32(bio->bi_bdev->bd_dev);
+	r.sector = cpu_to_be64(to);
+
+	__blk_add_trace(bt, from, bio->bi_size, bio->bi_rw, BLK_TA_REMAP,
+			!bio_flagged(bio, BIO_UPTODATE), sizeof(r), &r);
+}
+
+/**
+ * blk_add_driver_data - Add binary message with driver-specific data
+ * @q:		queue the io is for
+ * @rq:		io request
+ * @data:	driver-specific data
+ * @len:	length of driver-specific data
+ *
+ * Description:
+ *     Some drivers might want to write driver-specific data per request.
+ *
+ **/
+void blk_add_driver_data(struct request_queue *q,
+			 struct request *rq,
+			 void *data, size_t len)
+{
+	struct blk_trace *bt = q->blk_trace;
+
+	if (likely(!bt))
+		return;
+
+	if (blk_pc_request(rq))
+		__blk_add_trace(bt, 0, rq->data_len, 0, BLK_TA_DRV_DATA,
+				rq->errors, len, data);
+	else
+		__blk_add_trace(bt, rq->hard_sector, rq->hard_nr_sectors << 9,
+				0, BLK_TA_DRV_DATA, rq->errors, len, data);
+}
+EXPORT_SYMBOL_GPL(blk_add_driver_data);
+
+static int blk_register_tracepoints(void)
+{
+	int ret;
+
+	ret = register_trace_block_rq_abort(blk_add_trace_rq_abort);
+	WARN_ON(ret);
+	ret = register_trace_block_rq_insert(blk_add_trace_rq_insert);
+	WARN_ON(ret);
+	ret = register_trace_block_rq_issue(blk_add_trace_rq_issue);
+	WARN_ON(ret);
+	ret = register_trace_block_rq_requeue(blk_add_trace_rq_requeue);
+	WARN_ON(ret);
+	ret = register_trace_block_rq_complete(blk_add_trace_rq_complete);
+	WARN_ON(ret);
+	ret = register_trace_block_bio_bounce(blk_add_trace_bio_bounce);
+	WARN_ON(ret);
+	ret = register_trace_block_bio_complete(blk_add_trace_bio_complete);
+	WARN_ON(ret);
+	ret = register_trace_block_bio_backmerge(blk_add_trace_bio_backmerge);
+	WARN_ON(ret);
+	ret = register_trace_block_bio_frontmerge(blk_add_trace_bio_frontmerge);
+	WARN_ON(ret);
+	ret = register_trace_block_bio_queue(blk_add_trace_bio_queue);
+	WARN_ON(ret);
+	ret = register_trace_block_getrq(blk_add_trace_getrq);
+	WARN_ON(ret);
+	ret = register_trace_block_sleeprq(blk_add_trace_sleeprq);
+	WARN_ON(ret);
+	ret = register_trace_block_plug(blk_add_trace_plug);
+	WARN_ON(ret);
+	ret = register_trace_block_unplug_timer(blk_add_trace_unplug_timer);
+	WARN_ON(ret);
+	ret = register_trace_block_unplug_io(blk_add_trace_unplug_io);
+	WARN_ON(ret);
+	ret = register_trace_block_split(blk_add_trace_split);
+	WARN_ON(ret);
+	ret = register_trace_block_remap(blk_add_trace_remap);
+	WARN_ON(ret);
+	return 0;
+}
+
+static void blk_unregister_tracepoints(void)
+{
+	unregister_trace_block_remap(blk_add_trace_remap);
+	unregister_trace_block_split(blk_add_trace_split);
+	unregister_trace_block_unplug_io(blk_add_trace_unplug_io);
+	unregister_trace_block_unplug_timer(blk_add_trace_unplug_timer);
+	unregister_trace_block_plug(blk_add_trace_plug);
+	unregister_trace_block_sleeprq(blk_add_trace_sleeprq);
+	unregister_trace_block_getrq(blk_add_trace_getrq);
+	unregister_trace_block_bio_queue(blk_add_trace_bio_queue);
+	unregister_trace_block_bio_frontmerge(blk_add_trace_bio_frontmerge);
+	unregister_trace_block_bio_backmerge(blk_add_trace_bio_backmerge);
+	unregister_trace_block_bio_complete(blk_add_trace_bio_complete);
+	unregister_trace_block_bio_bounce(blk_add_trace_bio_bounce);
+	unregister_trace_block_rq_complete(blk_add_trace_rq_complete);
+	unregister_trace_block_rq_requeue(blk_add_trace_rq_requeue);
+	unregister_trace_block_rq_issue(blk_add_trace_rq_issue);
+	unregister_trace_block_rq_insert(blk_add_trace_rq_insert);
+	unregister_trace_block_rq_abort(blk_add_trace_rq_abort);
+
+	tracepoint_synchronize_unregister();
+}
diff --git a/block/elevator.c b/block/elevator.c
index 9ac82dd..530fcfe 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -33,6 +33,7 @@
 #include <linux/compiler.h>
 #include <linux/delay.h>
 #include <linux/blktrace_api.h>
+#include <trace/block.h>
 #include <linux/hash.h>
 #include <linux/uaccess.h>
 
@@ -586,7 +587,7 @@ void elv_insert(struct request_queue *q, struct request *rq, int where)
 	unsigned ordseq;
 	int unplug_it = 1;
 
-	blk_add_trace_rq(q, rq, BLK_TA_INSERT);
+	trace_block_rq_insert(q, rq);
 
 	rq->q = q;
 
@@ -772,7 +773,7 @@ struct request *elv_next_request(struct request_queue *q)
 			 * not be passed by new incoming requests
 			 */
 			rq->cmd_flags |= REQ_STARTED;
-			blk_add_trace_rq(q, rq, BLK_TA_ISSUE);
+			trace_block_rq_issue(q, rq);
 		}
 
 		if (!q->boundary_rq || q->boundary_rq == rq) {
@@ -921,7 +922,7 @@ void elv_abort_queue(struct request_queue *q)
 	while (!list_empty(&q->queue_head)) {
 		rq = list_entry_rq(q->queue_head.next);
 		rq->cmd_flags |= REQ_QUIET;
-		blk_add_trace_rq(q, rq, BLK_TA_ABORT);
+		trace_block_rq_abort(q, rq);
 		__blk_end_request(rq, -EIO, blk_rq_bytes(rq));
 	}
 }
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index c99e472..d23fda1 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -21,6 +21,7 @@
 #include <linux/idr.h>
 #include <linux/hdreg.h>
 #include <linux/blktrace_api.h>
+#include <trace/block.h>
 
 #define DM_MSG_PREFIX "core"
 
@@ -504,8 +505,7 @@ static void dec_pending(struct dm_io *io, int error)
 		end_io_acct(io);
 
 		if (io->error != DM_ENDIO_REQUEUE) {
-			blk_add_trace_bio(io->md->queue, io->bio,
-					  BLK_TA_COMPLETE);
+			trace_block_bio_complete(io->md->queue, io->bio);
 
 			bio_endio(io->bio, io->error);
 		}
@@ -598,7 +598,7 @@ static void __map_bio(struct dm_target *ti, struct bio *clone,
 	if (r == DM_MAPIO_REMAPPED) {
 		/* the bio has been remapped so dispatch it */
 
-		blk_add_trace_remap(bdev_get_queue(clone->bi_bdev), clone,
+		trace_block_remap(bdev_get_queue(clone->bi_bdev), clone,
 				    tio->io->bio->bi_bdev->bd_dev,
 				    clone->bi_sector, sector);
 
diff --git a/fs/bio.c b/fs/bio.c
index 77a55bc..060859c 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -26,6 +26,7 @@
 #include <linux/mempool.h>
 #include <linux/workqueue.h>
 #include <linux/blktrace_api.h>
+#include <trace/block.h>
 #include <scsi/sg.h>		/* for struct sg_iovec */
 
 static struct kmem_cache *bio_slab __read_mostly;
@@ -1263,7 +1264,7 @@ struct bio_pair *bio_split(struct bio *bi, int first_sectors)
 	if (!bp)
 		return bp;
 
-	blk_add_trace_pdu_int(bdev_get_queue(bi->bi_bdev), BLK_TA_SPLIT, bi,
+	trace_block_split(bdev_get_queue(bi->bi_bdev), bi,
 				bi->bi_sector + first_sectors);
 
 	BUG_ON(bi->bi_vcnt != 1);
diff --git a/include/linux/blktrace_api.h b/include/linux/blktrace_api.h
index bdf505d..1dba349 100644
--- a/include/linux/blktrace_api.h
+++ b/include/linux/blktrace_api.h
@@ -160,7 +160,6 @@ struct blk_trace {
 
 extern int blk_trace_ioctl(struct block_device *, unsigned, char __user *);
 extern void blk_trace_shutdown(struct request_queue *);
-extern void __blk_add_trace(struct blk_trace *, sector_t, int, int, u32, int, int, void *);
 extern int do_blk_trace_setup(struct request_queue *q,
 	char *name, dev_t dev, struct blk_user_trace_setup *buts);
 extern void __trace_note_message(struct blk_trace *, const char *fmt, ...);
@@ -186,168 +185,8 @@ extern void __trace_note_message(struct blk_trace *, const char *fmt, ...);
 	} while (0)
 #define BLK_TN_MAX_MSG		128
 
-/**
- * blk_add_trace_rq - Add a trace for a request oriented action
- * @q:		queue the io is for
- * @rq:		the source request
- * @what:	the action
- *
- * Description:
- *     Records an action against a request. Will log the bio offset + size.
- *
- **/
-static inline void blk_add_trace_rq(struct request_queue *q, struct request *rq,
-				    u32 what)
-{
-	struct blk_trace *bt = q->blk_trace;
-	int rw = rq->cmd_flags & 0x03;
-
-	if (likely(!bt))
-		return;
-
-	if (blk_discard_rq(rq))
-		rw |= (1 << BIO_RW_DISCARD);
-
-	if (blk_pc_request(rq)) {
-		what |= BLK_TC_ACT(BLK_TC_PC);
-		__blk_add_trace(bt, 0, rq->data_len, rw, what, rq->errors, sizeof(rq->cmd), rq->cmd);
-	} else  {
-		what |= BLK_TC_ACT(BLK_TC_FS);
-		__blk_add_trace(bt, rq->hard_sector, rq->hard_nr_sectors << 9, rw, what, rq->errors, 0, NULL);
-	}
-}
-
-/**
- * blk_add_trace_bio - Add a trace for a bio oriented action
- * @q:		queue the io is for
- * @bio:	the source bio
- * @what:	the action
- *
- * Description:
- *     Records an action against a bio. Will log the bio offset + size.
- *
- **/
-static inline void blk_add_trace_bio(struct request_queue *q, struct bio *bio,
-				     u32 what)
-{
-	struct blk_trace *bt = q->blk_trace;
-
-	if (likely(!bt))
-		return;
-
-	__blk_add_trace(bt, bio->bi_sector, bio->bi_size, bio->bi_rw, what, !bio_flagged(bio, BIO_UPTODATE), 0, NULL);
-}
-
-/**
- * blk_add_trace_generic - Add a trace for a generic action
- * @q:		queue the io is for
- * @bio:	the source bio
- * @rw:		the data direction
- * @what:	the action
- *
- * Description:
- *     Records a simple trace
- *
- **/
-static inline void blk_add_trace_generic(struct request_queue *q,
-					 struct bio *bio, int rw, u32 what)
-{
-	struct blk_trace *bt = q->blk_trace;
-
-	if (likely(!bt))
-		return;
-
-	if (bio)
-		blk_add_trace_bio(q, bio, what);
-	else
-		__blk_add_trace(bt, 0, 0, rw, what, 0, 0, NULL);
-}
-
-/**
- * blk_add_trace_pdu_int - Add a trace for a bio with an integer payload
- * @q:		queue the io is for
- * @what:	the action
- * @bio:	the source bio
- * @pdu:	the integer payload
- *
- * Description:
- *     Adds a trace with some integer payload. This might be an unplug
- *     option given as the action, with the depth at unplug time given
- *     as the payload
- *
- **/
-static inline void blk_add_trace_pdu_int(struct request_queue *q, u32 what,
-					 struct bio *bio, unsigned int pdu)
-{
-	struct blk_trace *bt = q->blk_trace;
-	__be64 rpdu = cpu_to_be64(pdu);
-
-	if (likely(!bt))
-		return;
-
-	if (bio)
-		__blk_add_trace(bt, bio->bi_sector, bio->bi_size, bio->bi_rw, what, !bio_flagged(bio, BIO_UPTODATE), sizeof(rpdu), &rpdu);
-	else
-		__blk_add_trace(bt, 0, 0, 0, what, 0, sizeof(rpdu), &rpdu);
-}
-
-/**
- * blk_add_trace_remap - Add a trace for a remap operation
- * @q:		queue the io is for
- * @bio:	the source bio
- * @dev:	target device
- * @from:	source sector
- * @to:		target sector
- *
- * Description:
- *     Device mapper or raid target sometimes need to split a bio because
- *     it spans a stripe (or similar). Add a trace for that action.
- *
- **/
-static inline void blk_add_trace_remap(struct request_queue *q, struct bio *bio,
-				       dev_t dev, sector_t from, sector_t to)
-{
-	struct blk_trace *bt = q->blk_trace;
-	struct blk_io_trace_remap r;
-
-	if (likely(!bt))
-		return;
-
-	r.device = cpu_to_be32(dev);
-	r.device_from = cpu_to_be32(bio->bi_bdev->bd_dev);
-	r.sector = cpu_to_be64(to);
-
-	__blk_add_trace(bt, from, bio->bi_size, bio->bi_rw, BLK_TA_REMAP, !bio_flagged(bio, BIO_UPTODATE), sizeof(r), &r);
-}
-
-/**
- * blk_add_driver_data - Add binary message with driver-specific data
- * @q:		queue the io is for
- * @rq:		io request
- * @data:	driver-specific data
- * @len:	length of driver-specific data
- *
- * Description:
- *     Some drivers might want to write driver-specific data per request.
- *
- **/
-static inline void blk_add_driver_data(struct request_queue *q,
-				       struct request *rq,
-				       void *data, size_t len)
-{
-	struct blk_trace *bt = q->blk_trace;
-
-	if (likely(!bt))
-		return;
-
-	if (blk_pc_request(rq))
-		__blk_add_trace(bt, 0, rq->data_len, 0, BLK_TA_DRV_DATA,
-				rq->errors, len, data);
-	else
-		__blk_add_trace(bt, rq->hard_sector, rq->hard_nr_sectors << 9,
-				0, BLK_TA_DRV_DATA, rq->errors, len, data);
-}
-
+extern void blk_add_driver_data(struct request_queue *q, struct request *rq,
+				void *data, size_t len);
 extern int blk_trace_setup(struct request_queue *q, char *name, dev_t dev,
 			   char __user *arg);
 extern int blk_trace_startstop(struct request_queue *q, int start);
@@ -356,13 +195,8 @@ extern int blk_trace_remove(struct request_queue *q);
 #else /* !CONFIG_BLK_DEV_IO_TRACE */
 #define blk_trace_ioctl(bdev, cmd, arg)		(-ENOTTY)
 #define blk_trace_shutdown(q)			do { } while (0)
-#define blk_add_trace_rq(q, rq, what)		do { } while (0)
-#define blk_add_trace_bio(q, rq, what)		do { } while (0)
-#define blk_add_trace_generic(q, rq, rw, what)	do { } while (0)
-#define blk_add_trace_pdu_int(q, what, bio, pdu)	do { } while (0)
-#define blk_add_trace_remap(q, bio, dev, f, t)	do {} while (0)
-#define blk_add_driver_data(q, rq, data, len)	do {} while (0)
 #define do_blk_trace_setup(q, name, dev, buts)	(-ENOTTY)
+#define blk_add_driver_data(q, rq, data, len)	do {} while (0)
 #define blk_trace_setup(q, name, dev, arg)	(-ENOTTY)
 #define blk_trace_startstop(q, start)		(-ENOTTY)
 #define blk_trace_remove(q)			(-ENOTTY)
diff --git a/include/trace/block.h b/include/trace/block.h
new file mode 100644
index 0000000..3cc2675
--- /dev/null
+++ b/include/trace/block.h
@@ -0,0 +1,60 @@
+#ifndef _TRACE_BLOCK_H
+#define _TRACE_BLOCK_H
+
+#include <linux/blkdev.h>
+#include <linux/tracepoint.h>
+
+DEFINE_TRACE(block_rq_abort,
+	TPPROTO(struct request_queue *q, struct request *rq),
+	TPARGS(q, rq));
+DEFINE_TRACE(block_rq_insert,
+	TPPROTO(struct request_queue *q, struct request *rq),
+	TPARGS(q, rq));
+DEFINE_TRACE(block_rq_issue,
+	TPPROTO(struct request_queue *q, struct request *rq),
+	TPARGS(q, rq));
+DEFINE_TRACE(block_rq_requeue,
+	TPPROTO(struct request_queue *q, struct request *rq),
+	TPARGS(q, rq));
+DEFINE_TRACE(block_rq_complete,
+	TPPROTO(struct request_queue *q, struct request *rq),
+	TPARGS(q, rq));
+DEFINE_TRACE(block_bio_bounce,
+	TPPROTO(struct request_queue *q, struct bio *bio),
+	TPARGS(q, bio));
+DEFINE_TRACE(block_bio_complete,
+	TPPROTO(struct request_queue *q, struct bio *bio),
+	TPARGS(q, bio));
+DEFINE_TRACE(block_bio_backmerge,
+	TPPROTO(struct request_queue *q, struct bio *bio),
+	TPARGS(q, bio));
+DEFINE_TRACE(block_bio_frontmerge,
+	TPPROTO(struct request_queue *q, struct bio *bio),
+	TPARGS(q, bio));
+DEFINE_TRACE(block_bio_queue,
+	TPPROTO(struct request_queue *q, struct bio *bio),
+	TPARGS(q, bio));
+DEFINE_TRACE(block_getrq,
+	TPPROTO(struct request_queue *q, struct bio *bio, int rw),
+	TPARGS(q, bio, rw));
+DEFINE_TRACE(block_sleeprq,
+	TPPROTO(struct request_queue *q, struct bio *bio, int rw),
+	TPARGS(q, bio, rw));
+DEFINE_TRACE(block_plug,
+	TPPROTO(struct request_queue *q),
+	TPARGS(q));
+DEFINE_TRACE(block_unplug_timer,
+	TPPROTO(struct request_queue *q),
+	TPARGS(q));
+DEFINE_TRACE(block_unplug_io,
+	TPPROTO(struct request_queue *q),
+	TPARGS(q));
+DEFINE_TRACE(block_split,
+	TPPROTO(struct request_queue *q, struct bio *bio, unsigned int pdu),
+	TPARGS(q, bio, pdu));
+DEFINE_TRACE(block_remap,
+	TPPROTO(struct request_queue *q, struct bio *bio, dev_t dev,
+		sector_t from, sector_t to),
+	TPARGS(q, bio, dev, from, to));
+
+#endif
diff --git a/mm/bounce.c b/mm/bounce.c
index 06722c4..bd1caaa 100644
--- a/mm/bounce.c
+++ b/mm/bounce.c
@@ -14,6 +14,7 @@
 #include <linux/hash.h>
 #include <linux/highmem.h>
 #include <linux/blktrace_api.h>
+#include <trace/block.h>
 #include <asm/tlbflush.h>
 
 #define POOL_SIZE	64
@@ -222,7 +223,7 @@ static void __blk_queue_bounce(struct request_queue *q, struct bio **bio_orig,
 	if (!bio)
 		return;
 
-	blk_add_trace_bio(q, *bio_orig, BLK_TA_BOUNCE);
+	trace_block_bio_bounce(q, *bio_orig);
 
 	/*
 	 * at least one page was bounced, fill in possible non-highmem
-- 
1.6.0.4.771.gef3b3


^ permalink raw reply related

* Re: linux-next: concerns over the perfmon3 tree
From: Ingo Molnar @ 2008-11-26 10:47 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: stephane eranian, linux-next, paulus, Andrew Morton,
	Thomas Gleixner, H. Peter Anvin
In-Reply-To: <20081126213449.ab269449.sfr@canb.auug.org.au>


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Stephane,
> 
> Given the concerns expressed by Ingo, I have dropped the perfmon3 
> tree from linux-next until they have been addressed.  Hopefully that 
> will not be loo long.  Let us all know how we can help with this.

Thanks, we'll try to finish the review ASAP (today+tomorrow) so that 
it can be added back in 1-2 days. And it's sensible to keep it in the 
separate perfmon3 tree as well (as long as it's not rebased) - that's 
a convenient initial structure for new features.

( and the powerpc bits would be nice as well, they seem to be missing
  from the current lineup - the more architectures keep hitting on 
  that code, the better the end result. )

	Ingo

^ permalink raw reply

* Re: linux-next: block tree build failure
From: Ingo Molnar @ 2008-11-26 10:42 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Jens Axboe, linux-next, Mathieu Desnoyers,
	Arnaldo Carvalho de Melo
In-Reply-To: <20081126212920.f992f7a5.sfr@canb.auug.org.au>


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Jens,
> 
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
> 
> In file included from block/blk-core.c:31:
> include/trace/block.h:9:15: error: macro "DEFINE_TRACE" passed 3 arguments, but takes just 1
> In file included from block/blk-core.c:31:
> include/trace/block.h:7: warning: data definition has no type or storage class
> include/trace/block.h:7: warning: type defaults to 'int' in declaration of 'DEFINE_TRACE'
> 
> and many more.  This is caused by commit 
> 714d010b5c249c2e9282515e0a2309a61ababbf4 ("blktrace: port to 
> tracepoints") interacting with commit 
> 7e066fb870fcd1025ec3ba7bbde5d541094f4ce1 ("tracepoints: add 
> DECLARE_TRACE () and DEFINE_TRACE()") which entered linux-next for 
> the first time today via the ftrace tree. This latter commit has 
> changed the tracepoints API.
> 
> I will drop the block tree for today.  I am not sure of the way forward.

hm, i think that might be interaction between ftrace tree updates and 
blktrace?

Jens, would it be fine with you if we created a new 
tip/tracing/blktrace branch and picked up your changes and kept it all 
uptodate and merged with the ftrace tree? It should merge fine with 
other bits of the block tree, right? (the tracepoints are in rather 
stable spots of the code i think)

the other direction (you merging ftrace bits) doesnt look too hot, 
you'd have to pick up:

   95 files changed, 5308 insertions(+), 1603 deletions(-)

	Ingo

^ permalink raw reply

* linux-next: concerns over the perfmon3 tree
From: Stephen Rothwell @ 2008-11-26 10:34 UTC (permalink / raw)
  To: stephane eranian
  Cc: linux-next, paulus, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

Hi Stephane,

Given the concerns expressed by Ingo, I have dropped the perfmon3 tree
from linux-next until they have been addressed.  Hopefully that will not
be loo long.  Let us all know how we can help with this.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* linux-next: block tree build failure
From: Stephen Rothwell @ 2008-11-26 10:29 UTC (permalink / raw)
  To: Jens Axboe
  Cc: linux-next, Mathieu Desnoyers, Ingo Molnar,
	Arnaldo Carvalho de Melo

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

Hi Jens,

Today's linux-next build (powerpc ppc64_defconfig) failed like this:

In file included from block/blk-core.c:31:
include/trace/block.h:9:15: error: macro "DEFINE_TRACE" passed 3 arguments, but takes just 1
In file included from block/blk-core.c:31:
include/trace/block.h:7: warning: data definition has no type or storage class
include/trace/block.h:7: warning: type defaults to 'int' in declaration of 'DEFINE_TRACE'

and many more.  This is caused by commit
714d010b5c249c2e9282515e0a2309a61ababbf4 ("blktrace: port to
tracepoints") interacting with commit
7e066fb870fcd1025ec3ba7bbde5d541094f4ce1 ("tracepoints: add DECLARE_TRACE
() and DEFINE_TRACE()") which entered linux-next for the first time today
via the ftrace tree. This latter commit has changed the tracepoints API.

I will drop the block tree for today.  I am not sure of the way forward.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: linux-next: manual merge of the perfmon3 tree
From: Ingo Molnar @ 2008-11-26 10:21 UTC (permalink / raw)
  To: Andrew Morton
  Cc: eranian, Stephen Rothwell, linux-next, Alexander van Heukelum,
	the arch/x86 maintainers, H. Peter Anvin, Thomas Gleixner,
	Peter Zijlstra
In-Reply-To: <20081126010022.63049908.akpm@linux-foundation.org>


* Andrew Morton <akpm@linux-foundation.org> wrote:

> On Wed, 26 Nov 2008 09:46:04 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> 
> > _Especially_ if 
> > then the linux-next integrator also plays stupid about basic kernel 
> > workflow questions ;-)
> 
> He didn't.  I suggested to Stephane and Stephen that we get this 
> stuff into linux-next for a shot at 2.6.29 and that the collective 
> 'we' make an extra effort to get perfmon over the hump and merged 
> up.

Did you think of Cc:-ing the affected maintainers, as a basic 
courtesy, and to make sure it's aligned up with their next merge 
window plans? Inform them to warn them about upcoming conflicts and 
other possible trouble you are causing in the code they are 
maintaining.

I'm sure you must have noticed the x86 impact from that patchset:

 arch/x86/Kconfig                               |    2 +
 arch/x86/Makefile                              |    3 +
 arch/x86/ia32/ia32entry.S                      |    5 +
 arch/x86/include/asm/Kbuild                    |    1 +
 arch/x86/include/asm/irq_vectors.h             |    5 +
 arch/x86/include/asm/mach-default/entry_arch.h |    4 +
 arch/x86/include/asm/perfmon.h                 |   34 ++
 arch/x86/include/asm/perfmon_kern.h            |  438 +++++++++++++++++
 arch/x86/include/asm/thread_info.h             |    8 +-
 arch/x86/include/asm/unistd_32.h               |    5 +
 arch/x86/include/asm/unistd_64.h               |   11 +-
 arch/x86/kernel/entry_32.S                     |    2 +-
 arch/x86/kernel/entry_64.S                     |    8 +-
 arch/x86/kernel/irqinit_64.c                   |    5 +
 arch/x86/kernel/process_32.c                   |   10 +
 arch/x86/kernel/process_64.c                   |   10 +
 arch/x86/kernel/signal_32.c                    |    5 +
 arch/x86/kernel/signal_64.c                    |    5 +
 arch/x86/kernel/syscall_table_32.S             |    5 +
 arch/x86/oprofile/nmi_int.c                    |   10 +-
 arch/x86/perfmon/Kconfig                       |   33 ++
 arch/x86/perfmon/Makefile                      |    7 +
 arch/x86/perfmon/perfmon.c                     |  619 +++++++++++++++++++++++
 arch/x86/perfmon/perfmon_amd64.c               |  483 ++++++++++++++++++
 arch/x86/perfmon/perfmon_intel_arch.c          |  628 ++++++++++++++++++++++++
 25 files changed, 2340 insertions(+), 6 deletions(-)

There's a ton of RFC patches on lkml that affect x86, it's a naturally 
popular arch for various kernel features. Right now there's 4-5 RFC 
features on lkml that have an x86 impact. Should we NAK all of them as 
a precaution, just to be on the safe side against surprises?

> You missed that email, [...]

to put it into perspective, this is the single mail about this topic 
that you are referring to:

  http://lkml.org/lkml/2008/10/22/381

you wrote (well into the mail):

  | What it needs is a sustained effort to get it over the hump.  
  | How's about getting it into linux-next asap and then we all agree 
  | to do the re-re-re-review and runtime testing for a 2.6.29 merge?

That was deep inside an existing discussion, and posed as a question.

The rest is probably private mails between you and sfr, right? No Cc: 
to the affected x86 maintainers and without any syncing with the merge 
schedule of the affected maintainers. How do you expect us to have 
magically deducted what you've done after that point privately?

And what would it have costed you to actually ... ask our opinion? To 
make sure everyone is on the same page? Instead of doing this all 
privately and behind our backs in essence?

> [...] missed the presence of perfmon in linux-next and repeatedly 
> chose to not review the perfmon patch series when it went past.

So every patch that touches lkml and has not specifically been NAK-ed 
by maintainers can show up in linux-next tomorrow, overlapping 
existing and well-maintained subsystem trees? That's a rather new 
concept to me that goes straight again all current maintenance 
practices and i think it is an absurd notion. It does not and it 
cannot work like that.

Sometimes we maintainers volunteer and review an pick up larger 
patches from lkml without being asked to. (we dont actually _have_ to, 
but we try to - the influx of patches and the plans for the cycle 
_ALWAYS_ has to be synced up with affected maintainers)

Sometimes, especially if a difficult merge is upcoming, we wait for 
them to be actively submitted to us and prioritize features based on 
review and testing feedback. Especially if it's the 10th version of a 
rather complex patchset that seemed to be getting nowhere.

Also, i asked this from you before and have not gotten an answer to it 
yet: how am i supposed to follow what goes into linux-next, in an 
efficient manner?

linux-next is a huge tree with 4000+ ever changing commits, and it is 
not at all transparent in the Git space: a ton of commits get rebased 
on a daily basis (all the quilt queues). There's no history of for 
example the 'linux-next/master/Trees' file either that would show and 
explain when and why trees were added to (or removed from) linux-next.

So linux-next has no proper reviewable history - unless you expect us 
to standardize on doing nothing but parsing linux-next changelogs all 
day.

_You_ certainly know what goes into linux-next, simply because you are 
the one who gets Cc:-ed to everything that goes into it. So you are in 
a fundamentally assymetric position. But how can you then expect 
symmetric awareness from us?

On the other hand i can and i do monitor what goes into Linus's tree, 
because it's a proper append-only Git tree. I can see all the merge 
decisions and activities in a very straightforward manner. The same is 
not possible with linux-next.

	Ingo

^ permalink raw reply

* Re: linux-next: net tree build failure
From: Stephen Rothwell @ 2008-11-26  9:40 UTC (permalink / raw)
  To: David Miller; +Cc: linux-next, herbert, kaber, adobriyan
In-Reply-To: <20081126.004513.58499930.davem@davemloft.net>

[-- Attachment #1: Type: text/plain, Size: 788 bytes --]

Hi Dave,

On Wed, 26 Nov 2008 00:45:13 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 26 Nov 2008 18:15:43 +1100
> 
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> 
> Stephen, thanks for all of these merge and build fixups.
> 
> I think I'll do a preemptive merge later today of net-2.6 into
> net-next-2.6 to try and resolve most of this.

Then when the poobah returns from slacking off and rejects some stuff we
both can grumble :-)

Thanks.

> But no promises as it's my birthday :)

Happy Birthday!  Have a really nice long lunch (like until next
Monday :-))

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: linux-next: manual merge of the perfmon3 tree
From: Peter Zijlstra @ 2008-11-26  9:31 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Ingo Molnar, eranian, Stephen Rothwell, linux-next,
	Alexander van Heukelum, the arch/x86 maintainers, H. Peter Anvin,
	Thomas Gleixner
In-Reply-To: <20081126010022.63049908.akpm@linux-foundation.org>

On Wed, 2008-11-26 at 01:00 -0800, Andrew Morton wrote:
> On Wed, 26 Nov 2008 09:46:04 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> 
> > _Especially_ if 
> > then the linux-next integrator also plays stupid about basic kernel 
> > workflow questions ;-)
> 
> He didn't.  I suggested to Stephane and Stephen that we get this stuff
> into linux-next for a shot at 2.6.29 and that the collective 'we' make
> an extra effort to get perfmon over the hump and merged up.
> 
> You missed that email, missed the presence of perfmon in linux-next
> and repeatedly chose to not review the perfmon patch series when it went
> past.
> 
> So here we all are.

It just seems to me that CC-ing the intended 'we' at that point would
have saved a lot of grief.

Stuffing 2.3k lines of code in without the maintainers ACK is not
something we do each day, and I can understand them getting miffed about
that. I think every maintainer would consider such an action plain rude.

^ permalink raw reply

* Re: linux-next: manual merge of the perfmon3 tree
From: Andrew Morton @ 2008-11-26  9:00 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: eranian, Stephen Rothwell, linux-next, Alexander van Heukelum,
	the arch/x86 maintainers, H. Peter Anvin, Thomas Gleixner,
	Peter Zijlstra
In-Reply-To: <20081126084604.GN26036@elte.hu>

On Wed, 26 Nov 2008 09:46:04 +0100 Ingo Molnar <mingo@elte.hu> wrote:

> _Especially_ if 
> then the linux-next integrator also plays stupid about basic kernel 
> workflow questions ;-)

He didn't.  I suggested to Stephane and Stephen that we get this stuff
into linux-next for a shot at 2.6.29 and that the collective 'we' make
an extra effort to get perfmon over the hump and merged up.

You missed that email, missed the presence of perfmon in linux-next
and repeatedly chose to not review the perfmon patch series when it went
past.

So here we all are.

^ permalink raw reply

* Re: linux-next: manual merge of the perfmon3 tree
From: Ingo Molnar @ 2008-11-26  8:46 UTC (permalink / raw)
  To: eranian
  Cc: Stephen Rothwell, linux-next, Alexander van Heukelum,
	the arch/x86 maintainers, H. Peter Anvin, Thomas Gleixner,
	Peter Zijlstra, Andrew Morton
In-Reply-To: <7c86c4470811260032n64d69b04w5762e5f6cbd0cff9@mail.gmail.com>


* stephane eranian <eranian@googlemail.com> wrote:

> > We know and knew about the existence of the perfmon patches, but 
> > they were always in the vague RFC category and never directly 
> > submitted or Cc:-ed to us.
>
> As Stephen pointed out, the full patchset was posted on LKML in 
> October I never saw any comments from you or any other x86 
> maintainers. I always assumed you were ALL on LKML anyway.

There's nothing to be "pointed out" about that - i was well aware of 
the regular perfmon spam on lkml ;-)

What was done in stealth was its sudden "will go upstream in 1-2 
months" status change, and its showing up in linux-next. There was 
ample opportunity to Cc: the maintainers for all of those steps - when 
you sent the tree setup request to Stephen, etc.

Really, in such cases you are expected to ping the respective 
maintainers about what they think about it and whether there's any 
objections. If they only notice it via conflicts of problem patches in 
linux-next they'll (rightfully) go into grumpy mode. _Especially_ if 
then the linux-next integrator also plays stupid about basic kernel 
workflow questions ;-)

> I have reposted the full patchset yesterday on LKML but 
> unfortunately my script dropped the cc-list. I will repost today 
> making sure x86@kernel.org is cc'ed. I am sorry about that, it never 
> was intentional. I will be waiting for your feedback on the x86 
> code.

ok, thanks. That's all that is needed normally.

	Ingo

^ permalink raw reply

* Re: linux-next: net tree build failure
From: David Miller @ 2008-11-26  8:45 UTC (permalink / raw)
  To: sfr; +Cc: linux-next, herbert, kaber, adobriyan
In-Reply-To: <20081126181543.0d7fba17.sfr@canb.auug.org.au>

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 26 Nov 2008 18:15:43 +1100

> Today's linux-next build (x86_64 allmodconfig) failed like this:

Stephen, thanks for all of these merge and build fixups.

I think I'll do a preemptive merge later today of net-2.6 into
net-next-2.6 to try and resolve most of this.

But no promises as it's my birthday :)

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox