All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@redhat.com>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: Mathieu Desnoyers <compudj@krystal.dyndns.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH][v3] blktrace: conversion to tracepoints
Date: Mon, 3 Nov 2008 15:21:12 -0200	[thread overview]
Message-ID: <20081103172112.GB32603@ghostprotocols.net> (raw)
In-Reply-To: <20081030111144.GQ31673@kernel.dk>

Em Thu, Oct 30, 2008 at 12:11:45PM +0100, Jens Axboe escreveu:
> On Thu, Oct 30 2008, Arnaldo Carvalho de Melo wrote:
> > Yes, I tested it, run 'btrace /dev/sda' several times, while doing a
> > 45 GB backup using rsync over NFS, etc. So it should have exercised the
> > tracepoints use and repeated registrater/unregister cycles.
> 
> Awesome, just wanted to know what level of testing you had done (from
> "none" to "doesn't crash" to "actually works"), so thanks for that.

Jens,

	Now I'm working on the marker glue code for systemtap to use
these tracepoints and I noticed that one important piece of information
is not available unless one first uses blk_trace_ioctl to fill in
request_queue->blk_trace, that is request_queue->blk_trace->dev, i.e.
the device associated with the request_queue.

	Is there a way to, from the request_queue, get the dev? I guess
not, as if there would be you wouldn't have added it to struct
blk_trace...

	Would it be sane to add get struct block_device->bd_dev dev_t
info into struct request_queue at sd_probe time or most probably at some
more suitable routine in the device/disk registration sequence of
events?

	I am certainly missing lots of connections here, there are many
objects and relationships among these objects that may make the
association of a block_device with a request_queue not to be fixed all
the time, thus requiring the struct blk_trace ->dev field to be set up
at ioctl time, but I'm just trying to figure out how to remove the
requirement of a setup routine for the tracepoints to know what is the
dev_t associated with the request_queue they are getting as a parameter.

Best Regards,

- Arnaldo

  reply	other threads:[~2008-11-03 17:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-29 12:05 [PATCH][v2] blktrace: conversion to tracepoints Arnaldo Carvalho de Melo
2008-10-29 13:18 ` Jens Axboe
2008-10-29 15:50   ` Arnaldo Carvalho de Melo
2008-10-29 19:43   ` [PATCH][v3] " Arnaldo Carvalho de Melo
2008-10-30  7:31     ` Jens Axboe
2008-10-30 11:03       ` Arnaldo Carvalho de Melo
2008-10-30 11:11         ` Jens Axboe
2008-11-03 17:21           ` Arnaldo Carvalho de Melo [this message]
2008-11-03 17:22             ` Jens Axboe
2008-11-03 18:08               ` Arnaldo Carvalho de Melo
2008-11-07 14:29       ` Alan D. Brunelle
2008-11-07 14:32         ` Jens Axboe
2008-11-07 15:38           ` Arnaldo Carvalho de Melo
2008-10-30 14:44     ` [PATCH][v3] blktrace: conversion to tracepoints 2.6.27.4 backport Mathieu Desnoyers
2008-10-30 14:47       ` Arnaldo Carvalho de Melo
2008-10-29 15:17 ` [PATCH][v2] blktrace: conversion to tracepoints Mathieu Desnoyers

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20081103172112.GB32603@ghostprotocols.net \
    --to=acme@redhat.com \
    --cc=compudj@krystal.dyndns.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

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

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