> ИМХО если бы все было просто - сделала бы еще Нокия при
> разработке.ИМХО она и сделала.
> Значит 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 является узким местом и процессор работал на минимальной частоте. Так же там используется выравнивание и большой размер блока чтения.
