> ИМХО если бы все было просто - сделала бы еще Нокия при
> разработке.

ИМХО она и сделала.

> Значит IO в их примере оказалось
> совсем не халявным по CPU.

Он был халявный: "CPU:   7% usr  88% sys   0% nic   0% idle   4% io   0% irq   0% sirq" и упирался в скорость cpu. Потом они снизили в MMC driver clock rate, да бы узким место сделать io. Потом добавили задержку в драйвер, для демонстрации ситуации тормозной/кривой драйвер. В итоге получили "CPU:   0% usr  18% sys   0% nic   0% idle  48% io   0% irq  32% sirq".

>> Вторая проблема - sys как был 18% так и остался. Но вырос
>> sirq с 32% до 81%. Очевидно, что такого не должно быть.
> Кстати, cp с флешки на флешку (т.е.чтение+запись) выглядит ощутимо иначе чем dd
> с флешки в null (т.е. чтение). При cp - появляется iowait.
> При dd вникуда - процентов 20 CPU даже может быть idle,
> а основной потребитель cpu - sys. Такое ощущение что запись и
> чтение ощутимо разные по свойствам.

Совершенно верно. Я упустил, что скорость чтения и записи будет совершенно разной и соответственно для чтения может быть узким местом cpu, а для записи - io.

> А как это с DVFS-рм дружит? А то 100% cpu на разных
> частотах - разные. Если задачи недостаточно для подъема частоты - она
> не померяется в "тощих" процентах CPU - на пониженной частоте? Или
> ядро достаточно умное для какого-то масштабирования?

Да, там все как-то хитро подсчитывается (точно не вспомню - давно читал) и показания строятся так, как если бы cpu работал всегда на полной скорости. Иначе была бы ситуация - реальная нагрузка снижается, а показания top растут - админы бы застрелились.

> Запись разумеется медленнее (может оттуда и берется iowait?).

Совершенно верно! Финал детективной истории:

1. Если io реально быстрый - то узким местом становится cpu. Что отлично согласуется с вашими наблюдениями, в том числе и с нагревом процессора во время io и ускорением io при разгоне cpu.

2. Считаем сколько стоит io:
При скорости 20 МБ/c мы тратим 230 мА. Для wav получим: 230 / (20 * 1024 / 172) = 1.93 mA. В реальности будет меньше - так как чтение wav не будет приводить к повышению частоты cpu и повышенному потреблению. Обычно все алгоритмы управления частотой ждут некоторое время пред переходом на другую частоту, таким образом короткие пики нагрузки игнорируются.

3. Нагрузка на cpu зависит еще и от способа чтения  - есть ли выравнивание и от размера блока чтения. Используя dd можно найти оптимальный bs по скорости чтения.

4. Полученный результат вполне неплохо соотносится с моим для clip zip. У clip zip получилось меньше, так как там io является узким местом и процессор работал на минимальной частоте. Так же там используется выравнивание и большой размер блока чтения.