> Сообщество n900 вроде до сих пор живо.Ну да. Однако не думаю что кто-то захочет с 2.6.28 копаться. Майнлайн пилят. Но у него свои проблемы. Я не очень понимаю с каким юзермодом его потом используют - штатный софт подразумевает работающее 3D.
> Да и неужели за столько лет никто не озаботился?
ИМХО если бы все было просто - сделала бы еще Нокия при разработке.
> Это дает шанс проверить исправлена ли проблема, если исправлена - бэкпортировать в 2.6.28.
На именно нокии эксперименты с новыми ядрами по ряду причин достаточно достаточно утомительны. С 2.6.28 сменилась целая эпоха. Грубый прикидон показывает что это залет на разборки с бутлоадером (NOLO использует старый протокол и не DTB-aware) и наверное сборку своего рутфса (то что штатный взлетит с новым ядром - имхо не факт).
> Ну не в 6, а в 3.
Я с точки зрения времени работы их тестовой задачи. Без IO она закончилась в 6 раз быстрее. Значит IO в их примере оказалось совсем не халявным по CPU.
> Вторая проблема - sys как был 18% так и остался. Но вырос
> sirq с 32% до 81%. Очевидно, что такого не должно быть.
Кстати, cp с флешки на флешку (т.е.чтение+запись) выглядит ощутимо иначе чем dd с флешки в null (т.е. чтение). При cp - появляется iowait. При dd вникуда - процентов 20 CPU даже может быть idle, а основной потребитель cpu - sys. Такое ощущение что запись и чтение ощутимо разные по свойствам. Сильно долбить немолодой флеш тестовыми записями мне не хочется - что я буду делать если он помрет? :)
> Так как для random у них было 100% sys.
Это наверное логично - ядро впахивает генерируя PRNGом поток рандома?
> Что точно не так - неясно. Возможно там как-то криво многозадачность реализована.
А как это с DVFS-рм дружит? А то 100% cpu на разных частотах - разные. Если задачи недостаточно для подъема частоты - она не померяется в "тощих" процентах CPU - на пониженной частоте? Или ядро достаточно умное для какого-то масштабирования?
> Или их хак с добавлением задержки в драйвер привел к неадекватным результатам.
Больше всего похоже на то что в целом IO у них совсем не халявное по CPU. А то что какие-то циклы из iowait извлечь можно - ну ок.
> 1. Посмотрите сколько у вас занимает io, без параллельной нагрузки cpu.
Говорю же - много. Если cp - проц в полку, с упомянутым iowait и проч. Если dd с чтением вникуда и большими блоками - может даже процентов 20 idle появиться, основной потребитель - sys. Если что 230 ма - для чтения dd'ом в /dev/null bs=1M померяно.
> 2. Попробуйте другую нагрузку cpu, которая вообще никак не обращается к фс во время исполнения.
Так я и попробовал этот их фокус с urandom - он вроде в cpu как раз и упирается. При IO он даже с нормальным приоритетом проседает в примерно 2.5 раза. Очевидный вывод - что IO в этой системе - никак не халява по циклам CPU.
> Какая при этом получилась скорость чтения?
С внутренней emmc до 20 мегов в секунду. С карты - зависит от карты. Запись разумеется медленнее (может оттуда и берется iowait?).
