Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1339154 > unrolled thread

Re: mmc: Add CONFIG_MMC_BLOCK_MAX_SPEED

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: mmc: Add CONFIG_MMC_BLOCK_MAX_SPEED Pavel Machek <pavel@ucw.cz> - 2016-02-22 07:50 +0100
    Re: mmc: Add CONFIG_MMC_BLOCK_MAX_SPEED Mark Salyzyn <salyzyn@android.com> - 2016-02-22 17:10 +0100
      Re: mmc: Add CONFIG_MMC_BLOCK_MAX_SPEED Mark Salyzyn <salyzyn@android.com> - 2016-02-22 18:30 +0100
      Re: mmc: Add CONFIG_MMC_BLOCK_MAX_SPEED Pavel Machek <pavel@ucw.cz> - 2016-02-24 12:00 +0100

#1339154 — Re: mmc: Add CONFIG_MMC_BLOCK_MAX_SPEED

Hi!

On Thu 2016-02-04 12:29:07, Mark Salyzyn wrote:
> When CONFIG_MMC_BLOCK_MAX_SPEED is enabled, Expose max_read_speed,
> max_write_speed and cache_size controls to simulate a slow eMMC device.
> The boot default values for each respectively are
> CONFIG_MMC_BLOCK_MAX_READ_SPEED, CONFIG_MMC_BLOCK_MAX_WRITE_SPEED and
> CONFIG_MMC_BLOCK_CACHE_SIZE respectively; and if not defined are
> 0 (off), 0, (off) and 4 MB also respectively.

Extra , after 0.

Dunno. At minimum, I'd call the option something like
"MMC_DEBUG_MAX_SPEED" and the speeds should be really controlled via
/sys or something...

...and ... is there reason to limit it to mmc devices? Making
harddrive slow would make it useful for testing, too...

...and you have the /sys interface. Drop the config options?

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [next] | [standalone]

#1339691

On 02/21/2016 10:45 PM, Pavel Machek wrote:
> Hi!
>
> On Thu 2016-02-04 12:29:07, Mark Salyzyn wrote:
>> When CONFIG_MMC_BLOCK_MAX_SPEED is enabled, Expose max_read_speed,
>> max_write_speed and cache_size controls to simulate a slow eMMC device.
>> The boot default values for each respectively are
>> CONFIG_MMC_BLOCK_MAX_READ_SPEED, CONFIG_MMC_BLOCK_MAX_WRITE_SPEED and
>> CONFIG_MMC_BLOCK_CACHE_SIZE respectively; and if not defined are
>> 0 (off), 0, (off) and 4 MB also respectively.
> Extra , after 0.

Yes :-)
> Dunno. At minimum, I'd call the option something like
> "MMC_DEBUG_MAX_SPEED" and the speeds should be really controlled via
> /sys or something...

Are controlled by sys.  Concern over DEBUG_MAX_SPEED is the sys nodes 
changing name to debug_max_read_speed, etc, which would in turn result 
in a move to debugfs instead. Will have to think about all the side 
effects of such a move.

> ...and ... is there reason to limit it to mmc devices? Making
> harddrive slow would make it useful for testing, too...

The speed limit at this layer is not the same as in the block layer, the 
two methods would 'join' at the same value when one does sustained I/O 
most likely, but not at the random patterns we have experienced on the 
devices. We would like additional wiggle room to simulate eMMC stalls 
due to load leveling and other behaviors in the future. If we moved up a 
layer we would have to simulate head seek and rotational latency opening 
a can of worms we would feel best if left closed. View it as a political 
decision.
>
> ...and you have the /sys interface. Drop the config options?

I needed a start up default value for boot-time simulations. If just sys 
options, we would be applying the values far too late in the operation. 
I expect some other folks using this simulation would like to forgo an 
extended boot time, to have them set/reset under programmed control. I 
was covering two bases.
> Best regards,
> 									Pavel
Sincerely -- Mark Salyzyn

[toc] | [prev] | [next] | [standalone]

#1339748

Decided to switch to CONFIG_MMC_SIMULATE_MAX_SPEED (and now the thread 
has a new title) so as not to disturb the debugfs gohds. Added some 
documentation to help the cause.

Outstanding will be whether to move this up to the block layer, or let 
it lay in the mmc driver where we can continue to refine the speed and 
behavior simulation model.

Sincerely -- Mark Salyzyn

On 02/22/2016 08:04 AM, Mark Salyzyn wrote:
> On 02/21/2016 10:45 PM, Pavel Machek wrote:
>> Hi!
>>
>> On Thu 2016-02-04 12:29:07, Mark Salyzyn wrote:
>>> When CONFIG_MMC_BLOCK_MAX_SPEED is enabled, Expose max_read_speed,
>>> max_write_speed and cache_size controls to simulate a slow eMMC device.
>>> The boot default values for each respectively are
>>> CONFIG_MMC_BLOCK_MAX_READ_SPEED, CONFIG_MMC_BLOCK_MAX_WRITE_SPEED and
>>> CONFIG_MMC_BLOCK_CACHE_SIZE respectively; and if not defined are
>>> 0 (off), 0, (off) and 4 MB also respectively.
>> Extra , after 0.
>
> Yes :-)
>> Dunno. At minimum, I'd call the option something like
>> "MMC_DEBUG_MAX_SPEED" and the speeds should be really controlled via
>> /sys or something...
>
> Are controlled by sys.  Concern over DEBUG_MAX_SPEED is the sys nodes 
> changing name to debug_max_read_speed, etc, which would in turn result 
> in a move to debugfs instead. Will have to think about all the side 
> effects of such a move.
>
>> ...and ... is there reason to limit it to mmc devices? Making
>> harddrive slow would make it useful for testing, too...
>
> The speed limit at this layer is not the same as in the block layer, 
> the two methods would 'join' at the same value when one does sustained 
> I/O most likely, but not at the random patterns we have experienced on 
> the devices. We would like additional wiggle room to simulate eMMC 
> stalls due to load leveling and other behaviors in the future. If we 
> moved up a layer we would have to simulate head seek and rotational 
> latency opening a can of worms we would feel best if left closed. View 
> it as a political decision.
>>
>> ...and you have the /sys interface. Drop the config options?
>
> I needed a start up default value for boot-time simulations. If just 
> sys options, we would be applying the values far too late in the 
> operation. I expect some other folks using this simulation would like 
> to forgo an extended boot time, to have them set/reset under 
> programmed control. I was covering two bases.
>> Best regards,
>>                                     Pavel
> Sincerely -- Mark Salyzyn

[toc] | [prev] | [next] | [standalone]

#1341836

Hi!

> >...and you have the /sys interface. Drop the config options?
> 
> I needed a start up default value for boot-time simulations. If just sys
> options, we would be applying the values far too late in the
> operation. I

Ok, use module parameters (aka kernel command line options), then...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web