linux-mmc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: merez@codeaurora.org
To: Jens Axboe <axboe@kernel.dk>
Cc: merez@codeaurora.org, linux-mmc@vger.kernel.org,
	linux-arm-msm@vger.kernel.org,
	DOCUMENTATION <linux-doc@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 1/3] block: Add test-iosched scheduler
Date: Thu, 2 Aug 2012 06:16:48 -0700 (PDT)	[thread overview]
Message-ID: <340c1ff468880f247cc9377705edd6e4.squirrel@www.codeaurora.org> (raw)
In-Reply-To: <5017FDCE.5030700@kernel.dk>


On Tue, July 31, 2012 8:46 am, Jens Axboe wrote:
> On 07/31/2012 04:36 PM, merez@codeaurora.org wrote:
>> Hi Jens,
>>
>> Do you have comments on this patch?
>> Can we push it to kernel 3.6 version?
>
> I have questions - what is this good for? In other words, explain to me
> why this is useful code. And in particular why this cannot be done from
> userspace with bsg and block tracing?
>
> IOW, I'm dubious as to whether a new _io scheduler_ is the correct
> solution to the problem you have at hand.
>
> --
> Jens Axboe
>
>

The test scheduler allows us to control the dispatched requests and their
order without an interfering of other requests.
You can review the patches which depends on this patch in order to better
understand how it is used.
For example, in the eMMC4.5 packed commands feature, the MMC layer can
pack read or write requests (the packed requests must be of the same
direction). MMC layer will stop fetching the requests in case the packing
conditions are broken.
In order to test this feature we had to have a full control on the
requests that the MMC layer fetches and their order, so that we will be
able to determine if the expected behavior was actually achieved.
The test-iosched can call specific block device callbacks, for example for
checking the test results.
Also, in order to be able to run out tests on the main eMMC card that runs
in HS200, we cannot "shut down" the real FS requests, otherwise our phone
won't come up or crash.
The test-iosched allows us to delay the real FS requests until the end of
the test, therefore the tests can be done on the main eMMC card.

We chose not to use blocktrace due to the "real" FS requests interference
in the middle of the test.

I'm not familiar with bsg so I cannot tell if it can answer all the
requirements I specified above.

Thanks,
Maya

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

  reply	other threads:[~2012-08-02 13:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-31 14:25 [PATCH v5 1/3] block: Add test-iosched scheduler Maya Erez
2012-07-31 14:36 ` merez
2012-07-31 15:46   ` Jens Axboe
2012-08-02 13:16     ` merez [this message]
2012-08-28  6:36       ` merez

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=340c1ff468880f247cc9377705edd6e4.squirrel@www.codeaurora.org \
    --to=merez@codeaurora.org \
    --cc=axboe@kernel.dk \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@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).