[PATCH v1 1/1] mmc: block: replace __blk_end_request() with blk_end_request()

[PATCH v1 1/1] mmc: block: replace __blk_end_request() with blk_end_request()

[Subhash Jadavani]

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 at times may take up to 6.5ms with
spinlock held and irq disabled.

__blk_end_request() calls couple of functions and ftrace output
shows that blk_update_bidi_request() function is almost taking 6ms.
There are 2 function to end the current request: ___blk_end_request()
and blk_end_request(). Both these functions do same thing except
that blk_end_request() function doesn't take up the spinlock
while calling the blk_update_bidi_request().

This patch replaces all __blk_end_request() calls with
blk_end_request() and __blk_end_request_all() calls with
blk_end_request_all().

Testing done: 20 process concurrent read/write on sd card
and eMMC. Ran this test for almost a day on multicore system
and no errors observed.

Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
---
 drivers/mmc/card/block.c |   36 +++++++++---------------------------
 1 files changed, 9 insertions(+), 27 deletions(-)

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index b180965..437471a 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -861,9 +861,7 @@ out:
 		goto retry;
 	if (!err)
 		mmc_blk_reset_success(md, type);
-	spin_lock_irq(&md->lock);
-	__blk_end_request(req, err, blk_rq_bytes(req));
-	spin_unlock_irq(&md->lock);
+	blk_end_request(req, err, blk_rq_bytes(req));
 
 	return err ? 0 : 1;
 }
@@ -923,9 +921,7 @@ out:
 		goto retry;
 	if (!err)
 		mmc_blk_reset_success(md, type);
-	spin_lock_irq(&md->lock);
-	__blk_end_request(req, err, blk_rq_bytes(req));
-	spin_unlock_irq(&md->lock);
+	blk_end_request(req, err, blk_rq_bytes(req));
 
 	return err ? 0 : 1;
 }
@@ -940,9 +936,7 @@ static int mmc_blk_issue_flush(struct mmc_queue *mq, struct request *req)
 	if (ret)
 		ret = -EIO;
 
-	spin_lock_irq(&md->lock);
-	__blk_end_request_all(req, ret);
-	spin_unlock_irq(&md->lock);
+	blk_end_request_all(req, ret);
 
 	return ret ? 0 : 1;
 }
@@ -1241,14 +1235,10 @@ static int mmc_blk_cmd_err(struct mmc_blk_data *md, struct mmc_card *card,
 
 		blocks = mmc_sd_num_wr_blocks(card);
 		if (blocks != (u32)-1) {
-			spin_lock_irq(&md->lock);
-			ret = __blk_end_request(req, 0, blocks << 9);
-			spin_unlock_irq(&md->lock);
+			ret = blk_end_request(req, 0, blocks << 9);
 		}
 	} else {
-		spin_lock_irq(&md->lock);
-		ret = __blk_end_request(req, 0, brq->data.bytes_xfered);
-		spin_unlock_irq(&md->lock);
+		ret = blk_end_request(req, 0, brq->data.bytes_xfered);
 	}
 	return ret;
 }
@@ -1290,10 +1280,8 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *rqc)
 			 * A block was successfully transferred.
 			 */
 			mmc_blk_reset_success(md, type);
-			spin_lock_irq(&md->lock);
-			ret = __blk_end_request(req, 0,
+			ret = blk_end_request(req, 0,
 						brq->data.bytes_xfered);
-			spin_unlock_irq(&md->lock);
 			/*
 			 * If the blk_end_request function returns non-zero even
 			 * though all data has been transferred and no errors
@@ -1343,10 +1331,8 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *rqc)
 			 * time, so we only reach here after trying to
 			 * read a single sector.
 			 */
-			spin_lock_irq(&md->lock);
-			ret = __blk_end_request(req, -EIO,
+			ret = blk_end_request(req, -EIO,
 						brq->data.blksz);
-			spin_unlock_irq(&md->lock);
 			if (!ret)
 				goto start_new_req;
 			break;
@@ -1367,12 +1353,10 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *rqc)
 	return 1;
 
  cmd_abort:
-	spin_lock_irq(&md->lock);
 	if (mmc_card_removed(card))
 		req->cmd_flags |= REQ_QUIET;
 	while (ret)
-		ret = __blk_end_request(req, -EIO, blk_rq_cur_bytes(req));
-	spin_unlock_irq(&md->lock);
+		ret = blk_end_request(req, -EIO, blk_rq_cur_bytes(req));
 
  start_new_req:
 	if (rqc) {
@@ -1396,9 +1380,7 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, struct request *req)
 	ret = mmc_blk_part_switch(card, md);
 	if (ret) {
 		if (req) {
-			spin_lock_irq(&md->lock);
-			__blk_end_request_all(req, -EIO);
-			spin_unlock_irq(&md->lock);
+			blk_end_request_all(req, -EIO);
 		}
 		ret = 0;
 		goto out;
-- 
1.7.1.1

--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: [PATCH v1 1/1] mmc: block: replace __blk_end_request() with blk_end_request()

[Chris Ball]

Hi,

On Tue, Apr 10 2012, Subhash Jadavani wrote:
> This patch replaces all __blk_end_request() calls with
> blk_end_request() and __blk_end_request_all() calls with
> blk_end_request_all().
>
> Testing done: 20 process concurrent read/write on sd card
> and eMMC. Ran this test for almost a day on multicore system
> and no errors observed.

Is there a measurable improvement in throughput or latency that
you can show data for?

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

RE: [PATCH v1 1/1] mmc: block: replace __blk_end_request() with blk_end_request()

[Subhash Jadavani]

> -----Original Message-----
> From: Chris Ball [mailto:cjb@laptop.org]
> Sent: Wednesday, April 11, 2012 12:08 AM
> To: Subhash Jadavani
> Cc: linux-mmc@vger.kernel.org; linux-arm-msm@vger.kernel.org
> Subject: Re: [PATCH v1 1/1] mmc: block: replace __blk_end_request() with
> blk_end_request()
> 
> Hi,
> 
> On Tue, Apr 10 2012, Subhash Jadavani wrote:
> > This patch replaces all __blk_end_request() calls with
> > blk_end_request() and __blk_end_request_all() calls with
> > blk_end_request_all().
> >
> > Testing done: 20 process concurrent read/write on sd card and eMMC.
> > Ran this test for almost a day on multicore system and no errors
> > observed.
> 
> Is there a measurable improvement in throughput or latency that you can
show
> data for?

This change was not meant for improving MMC throughput; it's basically about
becoming fair to other threads/interrupts in the system. By holding spin
lock and interrupts disabled for longer duration, we won't allow other
threads/interrupts to run at all.
Actually slight performance degradation at file system level can be expected
as we are not holding the spin lock during blk_update_bidi_request() which
means our mmcqd thread may get preempted for other high priority thread or
any interrupt in the system.

These are performance numbers (100MB file write) with eMMC running in DDR
mode:

Without this patch:
	Name of the Test	Value	Unit	
	LMDD Read Test	53.79	MBPS
	LMDD Write Test	18.86	MBPS
	IOZONE  Read Test	51.65	MBPS
	IOZONE  Write Test	24.36	MBPS

With this patch:

	Name of the Test	Value	Unit	
	LMDD Read Test	52.94	MBPS	
	LMDD Write Test	16.70	MBPS	
	IOZONE  Read Test	52.08	MBPS	
	IOZONE  Write Test	23.29	MBPS	

Read numbers are fine. Write numbers are bit down (especially LMDD write),
may be because write requests normally have large transfer size and which
means there are chances that while mmcq is executing
blk_update_bidi_request(), it may get interrupted by interrupts or other
high priority thread.

Regards,
Subhash

> 
> Thanks,
> 
> - Chris.
> --
> Chris Ball   <cjb@laptop.org>   <http://printf.net/>
> One Laptop Per Child

RE: [PATCH v1 1/1] mmc: block: replace __blk_end_request() with blk_end_request()

[Subhash Jadavani]

Hi Chris,

> -----Original Message-----
> From: linux-arm-msm-owner@vger.kernel.org [mailto:linux-arm-msm-
> owner@vger.kernel.org] On Behalf Of Subhash Jadavani
> Sent: Wednesday, April 11, 2012 12:22 AM
> To: 'Chris Ball'
> Cc: linux-mmc@vger.kernel.org; linux-arm-msm@vger.kernel.org
> Subject: RE: [PATCH v1 1/1] mmc: block: replace __blk_end_request() with
> blk_end_request()
> 
> 
> 
> > -----Original Message-----
> > From: Chris Ball [mailto:cjb@laptop.org]
> > Sent: Wednesday, April 11, 2012 12:08 AM
> > To: Subhash Jadavani
> > Cc: linux-mmc@vger.kernel.org; linux-arm-msm@vger.kernel.org
> > Subject: Re: [PATCH v1 1/1] mmc: block: replace __blk_end_request()
> > with
> > blk_end_request()
> >
> > Hi,
> >
> > On Tue, Apr 10 2012, Subhash Jadavani wrote:
> > > This patch replaces all __blk_end_request() calls with
> > > blk_end_request() and __blk_end_request_all() calls with
> > > blk_end_request_all().
> > >
> > > Testing done: 20 process concurrent read/write on sd card and eMMC.
> > > Ran this test for almost a day on multicore system and no errors
> > > observed.
> >
> > Is there a measurable improvement in throughput or latency that you
> > can
> show
> > data for?
> 
> This change was not meant for improving MMC throughput; it's basically
about
> becoming fair to other threads/interrupts in the system. By holding spin
lock
> and interrupts disabled for longer duration, we won't allow other
> threads/interrupts to run at all.
> Actually slight performance degradation at file system level can be
expected as
> we are not holding the spin lock during blk_update_bidi_request() which
means
> our mmcqd thread may get preempted for other high priority thread or any
> interrupt in the system.
> 
> 
> These are performance numbers (100MB file write) with eMMC running in
> DDR
> mode:
> 
> Without this patch:
> 	Name of the Test	Value	Unit
> 	LMDD Read Test	53.79	MBPS
> 	LMDD Write Test	18.86	MBPS
> 	IOZONE  Read Test	51.65	MBPS
> 	IOZONE  Write Test	24.36	MBPS
> 
> With this patch:
> 
> 	Name of the Test	Value	Unit
> 	LMDD Read Test	52.94	MBPS
> 	LMDD Write Test	16.70	MBPS
> 	IOZONE  Read Test	52.08	MBPS
> 	IOZONE  Write Test	23.29	MBPS
> 
> Read numbers are fine. Write numbers are bit down (especially LMDD write),
> may be because write requests normally have large transfer size and which
> means there are chances that while mmcq is executing
> blk_update_bidi_request(), it may get interrupted by interrupts or other
high
> priority thread.

Any thoughts/suggestions on this patch and numbers?

Regards,
Subhash
> 
> Regards,
> Subhash
> 
> >
> > Thanks,
> >
> > - Chris.
> > --
> > Chris Ball   <cjb@laptop.org>   <http://printf.net/>
> > One Laptop Per Child
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm"
in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/1] mmc: block: replace __blk_end_request() with blk_end_request()

[Namjae Jeon]

Hi. Subhash.

Would you share which option you used in LMDD, iozone test ?

Thanks.

2012/4/18 Subhash Jadavani <subhashj@codeaurora.org>:
> Hi Chris,
>
>> -----Original Message-----
>> From: linux-arm-msm-owner@vger.kernel.org [mailto:linux-arm-msm-
>> owner@vger.kernel.org] On Behalf Of Subhash Jadavani
>> Sent: Wednesday, April 11, 2012 12:22 AM
>> To: 'Chris Ball'
>> Cc: linux-mmc@vger.kernel.org; linux-arm-msm@vger.kernel.org
>> Subject: RE: [PATCH v1 1/1] mmc: block: replace __blk_end_request() with
>> blk_end_request()
>>
>>
>>
>> > -----Original Message-----
>> > From: Chris Ball [mailto:cjb@laptop.org]
>> > Sent: Wednesday, April 11, 2012 12:08 AM
>> > To: Subhash Jadavani
>> > Cc: linux-mmc@vger.kernel.org; linux-arm-msm@vger.kernel.org
>> > Subject: Re: [PATCH v1 1/1] mmc: block: replace __blk_end_request()
>> > with
>> > blk_end_request()
>> >
>> > Hi,
>> >
>> > On Tue, Apr 10 2012, Subhash Jadavani wrote:
>> > > This patch replaces all __blk_end_request() calls with
>> > > blk_end_request() and __blk_end_request_all() calls with
>> > > blk_end_request_all().
>> > >
>> > > Testing done: 20 process concurrent read/write on sd card and eMMC.
>> > > Ran this test for almost a day on multicore system and no errors
>> > > observed.
>> >
>> > Is there a measurable improvement in throughput or latency that you
>> > can
>> show
>> > data for?
>>
>> This change was not meant for improving MMC throughput; it's basically
> about
>> becoming fair to other threads/interrupts in the system. By holding spin
> lock
>> and interrupts disabled for longer duration, we won't allow other
>> threads/interrupts to run at all.
>> Actually slight performance degradation at file system level can be
> expected as
>> we are not holding the spin lock during blk_update_bidi_request() which
> means
>> our mmcqd thread may get preempted for other high priority thread or any
>> interrupt in the system.
>>
>>
>> These are performance numbers (100MB file write) with eMMC running in
>> DDR
>> mode:
>>
>> Without this patch:
>>       Name of the Test        Value   Unit
>>       LMDD Read Test  53.79   MBPS
>>       LMDD Write Test 18.86   MBPS
>>       IOZONE  Read Test       51.65   MBPS
>>       IOZONE  Write Test      24.36   MBPS
>>
>> With this patch:
>>
>>       Name of the Test        Value   Unit
>>       LMDD Read Test  52.94   MBPS
>>       LMDD Write Test 16.70   MBPS
>>       IOZONE  Read Test       52.08   MBPS
>>       IOZONE  Write Test      23.29   MBPS
>>
>> Read numbers are fine. Write numbers are bit down (especially LMDD write),
>> may be because write requests normally have large transfer size and which
>> means there are chances that while mmcq is executing
>> blk_update_bidi_request(), it may get interrupted by interrupts or other
> high
>> priority thread.
>
> Any thoughts/suggestions on this patch and numbers?
>
> Regards,
> Subhash
>>
>> Regards,
>> Subhash
>>
>> >
>> > Thanks,
>> >
>> > - Chris.
>> > --
>> > Chris Ball   <cjb@laptop.org>   <http://printf.net/>
>> > One Laptop Per Child
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm"
> in the
>> body of a message to majordomo@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>
> --
> 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

RE: [PATCH v1 1/1] mmc: block: replace __blk_end_request() with blk_end_request()

[Subhash Jadavani]

Hi Namjae,

> -----Original Message-----
> From: Namjae Jeon [mailto:linkinjeon@gmail.com]
> Sent: Wednesday, April 18, 2012 11:12 AM
> To: Subhash Jadavani
> Cc: Chris Ball; linux-mmc@vger.kernel.org; linux-arm-msm@vger.kernel.org
> Subject: Re: [PATCH v1 1/1] mmc: block: replace __blk_end_request() with
> blk_end_request()
> 
> Hi. Subhash.
> 
> Would you share which option you used in LMDD, iozone test ?

Following are the commands. Page cache is flushed before next iteration. Original numbers shared were average of almost 10 iterations.

LMDD:
	100MB file read/write:
		write:
			lmdd if=internal of=/data/datafile bs=128k count=800 flush=1 sync=1
		read:
			lmdd if=/data/datafile of=internal bs=128k flush=1 sync=1

IOZONE:
	100MB file read/write:
		Write:
			iozone -i0 -s100m -r128k -e -w -f /data/datafile -U /data/
		Read:
			iozone -i1 -s100m -r128k -e -f /data/datafile -U /data/

Regards,
Subhash

> 
> Thanks.
> 
> 2012/4/18 Subhash Jadavani <subhashj@codeaurora.org>:
> > Hi Chris,
> >
> >> -----Original Message-----
> >> From: linux-arm-msm-owner@vger.kernel.org [mailto:linux-arm-msm-
> >> owner@vger.kernel.org] On Behalf Of Subhash Jadavani
> >> Sent: Wednesday, April 11, 2012 12:22 AM
> >> To: 'Chris Ball'
> >> Cc: linux-mmc@vger.kernel.org; linux-arm-msm@vger.kernel.org
> >> Subject: RE: [PATCH v1 1/1] mmc: block: replace __blk_end_request()
> >> with
> >> blk_end_request()
> >>
> >>
> >>
> >> > -----Original Message-----
> >> > From: Chris Ball [mailto:cjb@laptop.org]
> >> > Sent: Wednesday, April 11, 2012 12:08 AM
> >> > To: Subhash Jadavani
> >> > Cc: linux-mmc@vger.kernel.org; linux-arm-msm@vger.kernel.org
> >> > Subject: Re: [PATCH v1 1/1] mmc: block: replace __blk_end_request()
> >> > with
> >> > blk_end_request()
> >> >
> >> > Hi,
> >> >
> >> > On Tue, Apr 10 2012, Subhash Jadavani wrote:
> >> > > This patch replaces all __blk_end_request() calls with
> >> > > blk_end_request() and __blk_end_request_all() calls with
> >> > > blk_end_request_all().
> >> > >
> >> > > Testing done: 20 process concurrent read/write on sd card and eMMC.
> >> > > Ran this test for almost a day on multicore system and no errors
> >> > > observed.
> >> >
> >> > Is there a measurable improvement in throughput or latency that you
> >> > can
> >> show
> >> > data for?
> >>
> >> This change was not meant for improving MMC throughput; it's
> >> basically
> > about
> >> becoming fair to other threads/interrupts in the system. By holding
> >> spin
> > lock
> >> and interrupts disabled for longer duration, we won't allow other
> >> threads/interrupts to run at all.
> >> Actually slight performance degradation at file system level can be
> > expected as
> >> we are not holding the spin lock during blk_update_bidi_request()
> >> which
> > means
> >> our mmcqd thread may get preempted for other high priority thread or
> >> any interrupt in the system.
> >>
> >>
> >> These are performance numbers (100MB file write) with eMMC running in
> >> DDR
> >> mode:
> >>
> >> Without this patch:
> >>       Name of the Test        Value   Unit
> >>       LMDD Read Test  53.79   MBPS
> >>       LMDD Write Test 18.86   MBPS
> >>       IOZONE  Read Test       51.65   MBPS
> >>       IOZONE  Write Test      24.36   MBPS
> >>
> >> With this patch:
> >>
> >>       Name of the Test        Value   Unit
> >>       LMDD Read Test  52.94   MBPS
> >>       LMDD Write Test 16.70   MBPS
> >>       IOZONE  Read Test       52.08   MBPS
> >>       IOZONE  Write Test      23.29   MBPS
> >>
> >> Read numbers are fine. Write numbers are bit down (especially LMDD
> >> write), may be because write requests normally have large transfer
> >> size and which means there are chances that while mmcq is executing
> >> blk_update_bidi_request(), it may get interrupted by interrupts or
> >> other
> > high
> >> priority thread.
> >
> > Any thoughts/suggestions on this patch and numbers?
> >
> > Regards,
> > Subhash
> >>
> >> Regards,
> >> Subhash
> >>
> >> >
> >> > Thanks,
> >> >
> >> > - Chris.
> >> > --
> >> > Chris Ball   <cjb@laptop.org>   <http://printf.net/> One Laptop Per
> >> > Child
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm"
> > in the
> >> body of a message to majordomo@vger.kernel.org More majordomo info at
> >> http://vger.kernel.org/majordomo-info.html
> >
> > --
> > 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

RE: [PATCH v1 1/1] mmc: block: replace __blk_end_request() with blk_end_request()

[Subhash Jadavani]

Hi Chris,

Do you see any issues with this patch?

Regards,
Subhash

> -----Original Message-----
> From: Subhash Jadavani [mailto:subhashj@codeaurora.org]
> Sent: Wednesday, April 18, 2012 1:07 PM
> To: 'Namjae Jeon'
> Cc: 'Chris Ball'; 'linux-mmc@vger.kernel.org'; 'linux-arm-
> msm@vger.kernel.org'
> Subject: RE: [PATCH v1 1/1] mmc: block: replace __blk_end_request() with
> blk_end_request()
> 
> Hi Namjae,
> 
> > -----Original Message-----
> > From: Namjae Jeon [mailto:linkinjeon@gmail.com]
> > Sent: Wednesday, April 18, 2012 11:12 AM
> > To: Subhash Jadavani
> > Cc: Chris Ball; linux-mmc@vger.kernel.org;
> > linux-arm-msm@vger.kernel.org
> > Subject: Re: [PATCH v1 1/1] mmc: block: replace __blk_end_request()
> > with
> > blk_end_request()
> >
> > Hi. Subhash.
> >
> > Would you share which option you used in LMDD, iozone test ?
> 
> Following are the commands. Page cache is flushed before next iteration.
> Original numbers shared were average of almost 10 iterations.
> 
> LMDD:
> 	100MB file read/write:
> 		write:
> 			lmdd if=internal of=/data/datafile bs=128k count=800
> flush=1 sync=1
> 		read:
> 			lmdd if=/data/datafile of=internal bs=128k flush=1
> sync=1
> 
> IOZONE:
> 	100MB file read/write:
> 		Write:
> 			iozone -i0 -s100m -r128k -e -w -f /data/datafile -U
> /data/
> 		Read:
> 			iozone -i1 -s100m -r128k -e -f /data/datafile -U /data/
> 
> Regards,
> Subhash
> 
> >
> > Thanks.
> >
> > 2012/4/18 Subhash Jadavani <subhashj@codeaurora.org>:
> > > Hi Chris,
> > >
> > >> -----Original Message-----
> > >> From: linux-arm-msm-owner@vger.kernel.org [mailto:linux-arm-msm-
> > >> owner@vger.kernel.org] On Behalf Of Subhash Jadavani
> > >> Sent: Wednesday, April 11, 2012 12:22 AM
> > >> To: 'Chris Ball'
> > >> Cc: linux-mmc@vger.kernel.org; linux-arm-msm@vger.kernel.org
> > >> Subject: RE: [PATCH v1 1/1] mmc: block: replace __blk_end_request()
> > >> with
> > >> blk_end_request()
> > >>
> > >>
> > >>
> > >> > -----Original Message-----
> > >> > From: Chris Ball [mailto:cjb@laptop.org]
> > >> > Sent: Wednesday, April 11, 2012 12:08 AM
> > >> > To: Subhash Jadavani
> > >> > Cc: linux-mmc@vger.kernel.org; linux-arm-msm@vger.kernel.org
> > >> > Subject: Re: [PATCH v1 1/1] mmc: block: replace
> > >> > __blk_end_request() with
> > >> > blk_end_request()
> > >> >
> > >> > Hi,
> > >> >
> > >> > On Tue, Apr 10 2012, Subhash Jadavani wrote:
> > >> > > This patch replaces all __blk_end_request() calls with
> > >> > > blk_end_request() and __blk_end_request_all() calls with
> > >> > > blk_end_request_all().
> > >> > >
> > >> > > Testing done: 20 process concurrent read/write on sd card and
> eMMC.
> > >> > > Ran this test for almost a day on multicore system and no
> > >> > > errors observed.
> > >> >
> > >> > Is there a measurable improvement in throughput or latency that
> > >> > you can
> > >> show
> > >> > data for?
> > >>
> > >> This change was not meant for improving MMC throughput; it's
> > >> basically
> > > about
> > >> becoming fair to other threads/interrupts in the system. By holding
> > >> spin
> > > lock
> > >> and interrupts disabled for longer duration, we won't allow other
> > >> threads/interrupts to run at all.
> > >> Actually slight performance degradation at file system level can be
> > > expected as
> > >> we are not holding the spin lock during blk_update_bidi_request()
> > >> which
> > > means
> > >> our mmcqd thread may get preempted for other high priority thread
> > >> or any interrupt in the system.
> > >>
> > >>
> > >> These are performance numbers (100MB file write) with eMMC running
> > >> in DDR
> > >> mode:
> > >>
> > >> Without this patch:
> > >>       Name of the Test        Value   Unit
> > >>       LMDD Read Test  53.79   MBPS
> > >>       LMDD Write Test 18.86   MBPS
> > >>       IOZONE  Read Test       51.65   MBPS
> > >>       IOZONE  Write Test      24.36   MBPS
> > >>
> > >> With this patch:
> > >>
> > >>       Name of the Test        Value   Unit
> > >>       LMDD Read Test  52.94   MBPS
> > >>       LMDD Write Test 16.70   MBPS
> > >>       IOZONE  Read Test       52.08   MBPS
> > >>       IOZONE  Write Test      23.29   MBPS
> > >>
> > >> Read numbers are fine. Write numbers are bit down (especially LMDD
> > >> write), may be because write requests normally have large transfer
> > >> size and which means there are chances that while mmcq is executing
> > >> blk_update_bidi_request(), it may get interrupted by interrupts or
> > >> other
> > > high
> > >> priority thread.
> > >
> > > Any thoughts/suggestions on this patch and numbers?
> > >
> > > Regards,
> > > Subhash
> > >>
> > >> Regards,
> > >> Subhash
> > >>
> > >> >
> > >> > Thanks,
> > >> >
> > >> > - Chris.
> > >> > --
> > >> > Chris Ball   <cjb@laptop.org>   <http://printf.net/> One Laptop
> > >> > Per Child
> > >>
> > >> --
> > >> To unsubscribe from this list: send the line "unsubscribe linux-arm-
> msm"
> > > in the
> > >> body of a message to majordomo@vger.kernel.org More majordomo
> info
> > >> at http://vger.kernel.org/majordomo-info.html
> > >
> > > --
> > > 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

Re: [PATCH v1 1/1] mmc: block: replace __blk_end_request() with blk_end_request()

[Chris Ball]

Hi,

On Sat, May 19 2012, Subhash Jadavani wrote:
> Do you see any issues with this patch?

No, no issues -- please could I ask you to refresh it against 3.5-rc1
(it no longer applies) and add your performance numbers to the commit
message?  I'll push it to mmc-next and probably merge for 3.6, so that
we have a full round of linux-next for anyone to notice problems.

Thanks!

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

RE: [PATCH v1 1/1] mmc: block: replace __blk_end_request() with blk_end_request()

[Subhash Jadavani]

> -----Original Message-----
> From: Chris Ball [mailto:cjb@laptop.org]
> Sent: Wednesday, June 06, 2012 7:01 PM
> To: Subhash Jadavani
> Cc: linux-mmc@vger.kernel.org; linux-arm-msm@vger.kernel.org; 'Namjae
> Jeon'
> Subject: Re: [PATCH v1 1/1] mmc: block: replace __blk_end_request() with
> blk_end_request()
> 
> Hi,
> 
> On Sat, May 19 2012, Subhash Jadavani wrote:
> > Do you see any issues with this patch?
> 
> No, no issues -- please could I ask you to refresh it against 3.5-rc1 (it
no longer
> applies) and add your performance numbers to the commit message?  I'll
push
> it to mmc-next and probably merge for 3.6, so that we have a full round of
> linux-next for anyone to notice problems.

Thanks Chris. I have posted v2 of this patch against mmc-next tip.

Regards,
Subhash

> 
> Thanks!
> 
> - Chris.
> --
> Chris Ball   <cjb@laptop.org>   <http://printf.net/>
> One Laptop Per Child