linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Subhash Jadavani" <subhashj@codeaurora.org>
To: linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>
Cc: linux-arm-msm@vger.kernel.org
Subject: RE: Changing the way MMC block request ends
Date: Fri, 6 Apr 2012 11:38:38 +0530	[thread overview]
Message-ID: <000001cd13bb$b774ce30$265e6a90$@codeaurora.org> (raw)
In-Reply-To: <000001cd12ef$69e743e0$3db5cba0$@codeaurora.org>

Hi Chris,

Any thoughts or suggestions on this?

Regards,
Subhash

> -----Original Message-----
> From: linux-mmc-owner@vger.kernel.org [mailto:linux-mmc-
> owner@vger.kernel.org] On Behalf Of Subhash Jadavani
> Sent: Thursday, April 05, 2012 11:16 AM
> To: linux-mmc@vger.kernel.org
> Cc: linux-arm-msm@vger.kernel.org
> Subject: Changing the way MMC block request ends
> 
> Hi,
> 
> For completing any block request, MMC block driver is calling:
>        spin_lock_irq(queue-lock)
>        __blk_end_request()
>        spin_unlock_irq(queue-lock)
> 
> But if we analyze the sources of latency in kernel using ftrace,
> __blk_end_request() function seems to hold a spinlock with interrupts
> disabled for up to 6.5 ms sometimes. __blk_end_request() calls couple of
> functions and ftrace output shows that blk_update_bidi_request() function
> is almost taking 6ms. So I was wondering why can't we use the
> blk_end_request() rather than __blk_end_request(). Both function does the
> same thing except blk_end_request() doesn't take up the spinlock while
> calling the blk_update_bidi_request(). Is there any race condition which
> could occur if we call blk_update_bidi_request() without queue lock?
> 
> I looked into blk_update_bidi_request() function and it mainly updates bio's
> of a request and doesn't look to do any manipulation with request queue
> structure of block device. There are many block drivers (SCSI, IDE etc .) other
> than MMC uses blk_end_request() rather than __blk_end_request(). Was
> there any special reason we are using __blk_end_request() in MMC block
> driver? If there is no specific reason, I would like to post a patch which would
> make MMC driver to use blk_end_request().
> 
> Let me know your thoughts on this.
> 
> Regards,
> Subhash
> 
> --
> Sent by a consultant of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
> Forum.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2012-04-06  6:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-05  5:46 Changing the way MMC block request ends Subhash Jadavani
2012-04-06  6:08 ` Subhash Jadavani [this message]
2012-04-06 13:54   ` Chris Ball
2012-04-06 14:08     ` Subhash Jadavani

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='000001cd13bb$b774ce30$265e6a90$@codeaurora.org' \
    --to=subhashj@codeaurora.org \
    --cc=cjb@laptop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-mmc@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).