From: "Subhash Jadavani" <subhashj@codeaurora.org>
To: 'Namjae Jeon' <linkinjeon@gmail.com>
Cc: 'Chris Ball' <cjb@laptop.org>,
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()
Date: Wed, 18 Apr 2012 13:06:36 +0530 [thread overview]
Message-ID: <000501cd1d35$fe0dec90$fa29c5b0$@codeaurora.org> (raw)
In-Reply-To: <CAKYAXd9QfEEJLQGG6PJgnNyyXP4D2Sa-PqhiZ=dDdQv50z76+A@mail.gmail.com>
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
next prev parent reply other threads:[~2012-04-18 7:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-10 18:26 [PATCH v1 1/1] mmc: block: replace __blk_end_request() with blk_end_request() Subhash Jadavani
2012-04-10 18:38 ` Chris Ball
2012-04-10 18:51 ` Subhash Jadavani
2012-04-18 5:15 ` Subhash Jadavani
2012-04-18 5:42 ` Namjae Jeon
2012-04-18 7:36 ` Subhash Jadavani [this message]
2012-05-19 11:04 ` Subhash Jadavani
2012-06-06 13:30 ` Chris Ball
2012-06-07 10:20 ` 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='000501cd1d35$fe0dec90$fa29c5b0$@codeaurora.org' \
--to=subhashj@codeaurora.org \
--cc=cjb@laptop.org \
--cc=linkinjeon@gmail.com \
--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 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.