Re: [PATCH] mmc: support BKOPS feature for eMMC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Hi Sebastian,

On Thu, Oct 27, 2011 at 10:51 PM, Sebastian Rasmussen <sebras@xxxxxxxxx> wrote:
> Hi!
>
>> This patch only starts BKOPS if it's urgent or critical.
>
> Almost, it starts BKOPS when it is urgent, which per spec means level
> 2 or 3, i.e. when performance is impacted or when it is critical.
> Better use the specs terminology as far as possible to relieve
> everyone of confusion.
>
>> I would be preferable to run bkops periodically and only when
>> the card is idle to minimize the risk of reaching URGENT.
>
> Well, you kind of need both.
Yes, this is what I mean. If the URGENT_BKOPS is set meaning (status 2
or 3) there is no escape, current solution will do fine.
Periodical check is a complement, not a replacement. Must BKOPS always
be deferred until performance is impacted?

About starvation.
What happens if the BKOPS never have time to finish because new writes
are coming in all the time. Is it possible to starve the
BKOPS-operation?
Will it come to a point when BKOPS must run without interruption?

> extent that the block device is never idling then you would definitely
> require this patch, right? Otherwise you may end up wasting the time
> between the last command sent and when the device has been deemed to
> be idle for long enough.
>
> So basically the OP's patch fixes the case where, e.g. sustained
> (re-)writing, keeps the block device busy until and after it reaches
> the critical BKOPS level, while your proposal takes care of the other
> case where the block device is not accessed all the time.
>
>> The specs says:
>> -----
>> Hosts shall still read the full status from the BKOPS_STATUS byte periodically
>> and start background operations as needed.
>> -----
>
> Sure, if there is idle time to do it, then why not.
> If there is no idle time and URGENT_BKOPS is asserted, then the
> framework can not wait until the next idle period, but should issue
> BKOPS as soon as possible after the current command is finished.
>
>> I'm thinking of checking BKOPS_STATUS when the card is idle and then run bkops
>> even if level is only 1 (Operations outstanding – non critical). Would this make
>> sense?
>
> I guess this boils down to how you define idle..? Does it mean
> immediately after the current command has been fully serviced, or does
> it mean some arbitrary time after the last sent command has been fully
> serviced? My assumption is that you are refering to the latter, in
> which case certain access patterns may cause problems. So, how do
> _you_ define idle? :)
My first point was just to raise my concern and start a discussion
about this. If this turns out to be a good idea I be happy to look
more into the details.

One question is:
Is it worth running BKOPS if the BKOPS_STATUS is only 1? I could run
some tests comparing write performance when status is 0,1,2.

I don't know what the best place would be for a BKOPS_STATUS check.
What comes to my mind is to use the same credentials that are used for
power save. I need to look more closely into this in order to propose
a patch.
Suspend? if suspend is requested one might check BKOPS_STATUS and
return -EBUSY if BKOPS needs to be started.

Regards,
Per
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]

Add to Google Powered by Linux