From: Ming Zhang <blackmagic02881@gmail.com>
To: linux-btrace@vger.kernel.org
Subject: Re: BLK_TA_ISSUE
Date: Thu, 12 Apr 2007 21:22:31 +0000 [thread overview]
Message-ID: <1176412951.3465.88.camel@fs0004.ibrix.com> (raw)
In-Reply-To: <1176341579.3409.2.camel@localhost.localdomain>
On Thu, 2007-04-12 at 23:16 +0200, Jens Axboe wrote:
> On Thu, Apr 12 2007, Ming Zhang wrote:
> > On Thu, 2007-04-12 at 13:29 +0200, Jens Axboe wrote:
> > > On Wed, Apr 11 2007, Ming Zhang wrote:
> > > > Hi All
> > > >
> > > > For this ISSUE event, currently it is in elv_next_request(), any idea
> > > > why it is not in elv_dequeue_request() which is where the request marked
> > > > as on-the-fly and send to lower level?
> > >
> > > elv_next_request() is the driver hand-off point, so should be pretty
> > > close to the issue time unless the request gets requeued due to some
> > > busy condition (which will also be logged). elv_dequeue_request() may
> > > happen much later, some drivers do it right before calling the io
> > > completion handler - IDE does this - since it leaves the request on the
> > > queue list for the duration of the operation. So moving the ISSUE event
> > > to elv_dequeue_request() would not be correct.
> > >
> >
> > ic. i assumed all requests will be removed from queue before llDD handle
> > it.
> >
> > in 2.6.20 ele_dequeue_request
> >
> > 771
> > 772 /*
> > 773 * the time frame between a request being removed from the lists
> > 774 * and to it is freed is accounted as io that is in progress at
> > 775 * the driver side.
> > 776 */
> > 777 if (blk_account_rq(rq))
> > 778 q->in_flight++;
> >
> > then this in_flight counter is more likely to be how many outstanding
> > requests that not in the queue and before it is free. and it might be
> > less than how many undergoing IOs?
>
> It's good enough for what ->in_flight is used for. Your assumption on
> that all low level drivers dequeue before handling a request is wrong.
> Usually only drivers that do queueing do this.
so u meant most driver will leave request in queue unless they do
internal queuing?
does this mean the queue can be unnecessary long and travel the list
will go through some requests that under io already?
>
next prev parent reply other threads:[~2007-04-12 21:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-12 1:32 BLK_TA_ISSUE Ming Zhang
2007-04-12 11:29 ` BLK_TA_ISSUE Jens Axboe
2007-04-12 13:18 ` BLK_TA_ISSUE Ming Zhang
2007-04-12 21:16 ` BLK_TA_ISSUE Jens Axboe
2007-04-12 21:22 ` Ming Zhang [this message]
2007-04-13 5:30 ` BLK_TA_ISSUE Jens Axboe
2007-04-13 13:18 ` BLK_TA_ISSUE Ming Zhang
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=1176412951.3465.88.camel@fs0004.ibrix.com \
--to=blackmagic02881@gmail.com \
--cc=linux-btrace@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.