[<prev] [next>] [day] [month] [year] [list]
Message-ID: <001801cd0f33$89daf7b0$9d90e710$@codeaurora.org>
Date: Sat, 31 Mar 2012 17:13:45 +0530
From: "Subhash Jadavani" <subhashj@...eaurora.org>
To: <linux-mmc@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Cc: <linux-arm-msm@...r.kernel.org>, "'Chris Ball'" <cjb@...top.org>
Subject: __blk_end_request vs blk_end_request
Hi,
For completing any block request, MMC block driver is calling:
spin_lock_irq(queue)
_blk_end_request()
spin_unlock_irq(queue)
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. Attached is ftrace output for this
function.
__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 cant we use the blk_end_request() rather than __blk_end_request(). Both
function does the same thing except blk_end_request() doesnt 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 I 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.
View attachment "ftrace-output.txt" of type "text/plain" (237951 bytes)
Powered by blists - more mailing lists