> ИМХО она и сделала.Однако в целом IO на этой системе достаточно дорогое, имхо.
> Он был халявный:
Странная какая-то халява все-таки. Особенно на нокии.
>> Такое ощущение что запись и чтение ощутимо разные по свойствам.
> Совершенно верно. Я упустил, что скорость чтения и записи будет совершенно разной
Для флеша такое различие - обычное дело. Я бы наверное мог бы и раньше догадаться, т.к. кухню флеша неплохо знаю.
> и соответственно для чтения может быть узким местом cpu, а для записи - io.
Действительно, так понятнее в чем фокус.
> Да, там все как-то хитро подсчитывается (точно не вспомню - давно читал)
> и показания строятся так, как если бы cpu работал всегда на полной скорости.
Вообще, логично. Я на всякий случай уточнил. А load avg я надеюсь это тоже касается? :)
> показания top растут - админы бы застрелились.
Ну да :)
>> Запись разумеется медленнее (может оттуда и берется iowait?).
> Совершенно верно! Финал детективной истории:
Ну да,
> 1. Если io реально быстрый - то узким местом становится cpu. Что
> отлично согласуется с вашими наблюдениями, в том числе и с нагревом
> процессора во время io и ускорением io при разгоне cpu.
Вообще, звучит логично. Хотя сами по себе 20 мегов в секунду для такого ARN - не так уж и много на самом деле.
> 2. Считаем сколько стоит io:
> При скорости 20 МБ/c мы тратим 230 мА. Для wav получим: 230
> / (20 * 1024 / 172) = 1.93 mA. В реальности
> будет меньше - так как чтение wav не будет приводить к
> повышению частоты cpu и повышенному потреблению.
Или больше. Потому что для чтения надо:
1) включить eMMC (и, возможно блок контроллера оной в omap),
2) дать все потребные клоки
А частота может и повыситься. У кого-то из governor даже такой tunable припоминается как повышать частоту при IO. Помогает вкостылить скорость IO на системах где иначе IO тормозит т.к. проц не разгоняется. А когда IO прекратится - пока dvfs прочухает, пока таймауты отключения блоков наступят и что там еще. Блок не имеет смысл отключать если к нему обращение вскоре ожидается: включение блоков сопряжено с некоей латенси. Она конечно не гигантская но и не ноль. А жизня научила нокию не срубать питание карточкам сразу после того как те отрапортовали что все готово. Были прецеденты дестроя карт и нокия чинила всю подсистему mmc в линухе. Этот фикс наверное всем разъехался у кого mmc хост есть. Хоть и снижает энергоэффективность, но дестрой транслятора на карте памяти воспринимается юзерами гораздо хуже. Хоть это и баг карт на самом деле.
Говоря за себя я не считаю линейное масштабирование чем-то априори-валидным для процессов с подобными свойствами. Все это имхо проверять надо.
> Обычно все алгоритмы управления частотой ждут некоторое время пред переходом
> на другую частоту, таким образом короткие пики нагрузки игнорируются.
И правильно делают, потому что латенси всего этого - не ноль. Сначала надо ведь скомандовать power manager поднять вольтаж, подождать пока импульсник этот вольтаж фактически накачает, и только тогда станет безопасно выставить новую частоту. Это работает и в обратную сторону до некоторой степени. С той разницей что свалить на низкую частоту с повышенным вольтажом ничем не чревато, поэтому можно и не ждать. А вот как показали натурные эксперименты, агрессивный power gating карт памяти - очень даже отливается.
> 3. Нагрузка на cpu зависит еще и от способа чтения -
> есть ли выравнивание и от размера блока чтения. Используя dd можно
> найти оптимальный bs по скорости чтения.
У флеша скорость чтения может зависеть еще и от того как это стыкуется с размером блока флеша и проч. Но я думаю что bs=1M был как минимум близким к оптимуму. Потому что вытаскивание одного такого блока - это образение сразу к большой куче страниц последовательно. Большинство других вариантов будет менее удачно.
> и процессор работал на минимальной частоте. Так же там используется выравнивание
> и большой размер блока чтения.
ИМХО с bs=1M выравнивание вышло само по себе. В том плане что при этом оверхед на все остальное будет небольшой а основная масса операций будет удобной для флеша. Вообще с флешом обращать на выравнивание больше смысла при записи. Если блоки ФС попадут на пересечения страниц флеша - будет полный трэш по скорости записи. Да и операции неплохо бы выравнивать не только по страницам но и по erase block, но они большие а истинную геометрию флехи - как максимум ее можно прикинуть. Еще в новых картах сделали discard вроде, но я не думаю что eMMC 2009 года это умеет. А значит при записи она всегда будет залетать на erase (длительная по времени штука) до того как сможет program.
