On 10/01/2011 11:20 PM, Andrei E. Warkentin wrote:
> Hi James,
>
> 2011/9/30 J Freyensee<james_p_freyensee@linux.intel.com>:
>>
>> So I have a question on write behavior.
>>
>> Say mmc_blk_issue_rw_rq() is called.  Say the mmc_queue *mq variable passed
>> in is a write.
>
> You mean the struct request?
>
>>   Say that write is buffered, delayed into being sent via
>> mmc_wait_for_req() for 5 seconds, and it's sent to mmc_wait_for_req() later.
>>   Would that delay of sending the brq->mrq entry to mmc_wait_for_req() cause
>> a timeout, ie:
>
> Are you working off of mmc-next? Sounds like you don't have Per
> Förlin's async work yet.
> I don't want to sound lame (yes, I know your Medfield or whatever
> projects build on a particular baseline),
> but you would be doing yourself a huge favor by doing your interesting
> investigations on top of the top of
> tree.

Yeah, I know I'd be doing myself a huge favor by working off of mmc-next 
(or close to it), but product-wise, my department doesn't care for 
sustaining current platforms...yet (still trying to convince).

>
> The old code indeed calls mmc_wait_for_req in  mmc_blk_issue_rw_rq,
> while the new code does a
> mmc_start_req, which waits for a previous async request to complete
> before issuing the new one.
>
> Could you describe in greater detail what you're doing? What exactly
> do you mean by buffering?

So I was looking into sticking a write cache into block.c driver as a 
parameter, so it can be turned on and off upon driver load.  Any write 
operation goes to the cache and only on a cache collision will the
write operation get sent to the host controller for a write.  What I 
have working so far is just with an MMC card in an MMC slot of a laptop, 
and just bare-bones.  No general flush routine, error-handling, etc. 
 From a couple performance measurements I did on the MMC slot using 
blktrace/blkparse and 400MB write transactions, I was seeing huge 
performance boost with no data corruption.  So it is not looking like a 
total hair-brained idea.  But I am still pretty far from understanding 
everything here.  And the real payoff we want to see is performance a 
user can see on a handheld (i.e., Android) systems.

I did attach the code if you do want to look at it.  I heavily commented 
the code additions I made so it shouldn't be too scary to follow.  Any 
kernel contributions in the past I have made have had similar coding 
documentation in it.  I have currently turned on debugging in the host 
controller so I'm trying to understand what is going on there.

Thanks,
Jay


> As far as I understand, until you call mmc_wait_for_req (old code) or
> mmc_start_req (new code), your
> request only exists as a data structure, and the host controller
> doesn't know or care about it. So it doesn't
> matter when you send it - now, or five seconds in the future (of
> course, you probably don't want other requests
> to get ahead of a barrier request).
>
> The mmc_set_data_timeout routine is used to calculate the time the
> host controller will wait for the card to
> process the read/write. This is obviously tied to the transfer size,
> type (read or write), card properties as inferred
> from its registers and technology.
>
>>
>> mmc0: Timeout waiting for hardware interrupt.
>>
>> ??
>>
>> If this is true, how would you extend the timeout?  I would not have
>> expected this until mmc_wait_for_req() is called.
>
> The fact that you got a timeout implies that the host was processing a
> struct mmc_request already.
>
>   It appeared to me
>> mmc_set_data_timeout() was just setting a variable in brq to be used when
>> mmc_wait_for_req() is called.  I only see this behavior in eMMC cards, not
>> MMC cards being stuck into an MMC slot of a laptop.
>>
>
> It's hard to say what is going without seeing some code. My other suggestion is
> instrument the host driver (and block driver as well) and figure out
> what request is failing
> and why.
>
> A


-- 
J (James/Jay) Freyensee
Storage Technology Group
Intel Corporation