Интервью с разработчиком TuxOnIce Найджелом Каннингемом

Александр Наталенко aka post-factum, 17.06.2011 г.

Откуда ты сам?

Я вырос в Окленде, Новая Зеландия, но последние 14 лет жил в Австралии. Сейчас обитаю в Джелонге, это немного южнее Мельбурна.

Программирование — твоя профессия? Когда ты начал им заниматься? Какой твой любимый язык программирования?

Вообще, про профессии я служитель христианской (протестантской) церкви, но до этого получил степень бакалавра торговли в области управления информационными системами и менеджмента.

Ещё ребёнком я был немного компьютерным гиком, но со временем меня стали больше интересовать люди, чем компьютеры. После окончания теологических курсов около 10 лет назад я занимался и ИТ, и христианским служением. То, чем занимаюсь я сейчас, объединяет эти две вещи. Я работаю в теологическом колледже Мельбурна, координируя их программу дистанционного обучения. Как часть этого я работаю над программным обеспечением электронного обучения, которое называется Moodle, а также занимаюсь главным веб-сайтом на Drupal’е.

Программировать я начал в раннем подростковом возрасте. Первым семейным компьютером был Dick Smith VZ-200 (он продавался в Австралии и Новой Зеландии), а потом у меня появился Commodore 64, на котором я и совершил первую попытку программировать. Я выучил машинный код до такой степени, что написал небольшую систему со всплывающим меню, код которой размещался большей частью в ОЗУ, которая обычно скрывалась 16 Кб базового ПЗУ компьютера C-64.

Я не уверен, что у меня есть любимый язык программирования. В основном, сейчас использую два: C для ядра и PHP для разработки веб-сайта. Они мне оба нравятся, но всему своё место: C хорош для программирования ядра, а PHP — для веб-сайтов. Если переиначить твой вопрос, то могу сказать, что Scheme я люблю меньше всего. Мне довелось его изучать во время выполнения задач по информатике, когда я учился на бакалавра, и я думаю, что эти все скобочки больше способствуют продаже таблеток от головной боли, чем читаемости кода! :)

Твои хобби?

Мне немного нравится ухаживать за растениями — вот сейчас я уже третий раз наблюдаю, как из почвы вырастают тюльпаны, я действительно люблю на них смотреть.

Также я являюсь активным членом местной аварийной службы — это группа волонтёров, которая помогает людям при наводнениях, штормах и в других чрезвычайных ситуациях. Мне действительно понравилось учиться безопасно лазить по крышам, регулировать движение и тому подобное, поэтому я с нетерпением жду прохождения других необходимых курсов, чтобы потом можно было на практике применить приобретённые навыки.

У тебя дома есть домашние животные (особенно интересуют коты, большинство наших читателей на них помешаны)? Как их зовут? Они тебе помогают программировать?

Стыдно признаться, нет у меня домашних животных. Но есть двое детишек, которых я очень люблю. У меня и моей жены Мишель 13-летний сын Элиздер (Alisdair) и 3-летняя дочь Ирен (Irene). Элиздер хочет научиться программировать, но пока не научился.

С чего началась разработка suspend2? Когда это началось? Почему название было «suspend2», а не «suspend»?

Работа над гибернацией началась лет 10 назад, когда я серьёзно начал заниматься Линуксом. В теологическом колледже мне захотелось запускать программы по изучению Библии, но они были только для Windows. Мне приходилось запускать сначала Линукс, потом Win4Lin, а потом Logos (та самая программа по изучению Библии). Это занимало каждый раз минут пять. И тут я начал смотреть на гибернацию как на инструмент убыстрения всего этого процесса.

Тогда гибернация была ещё не в ядре. Это было примерно во времена 2.4.16 и ранних версий ветки 2.5. Габор Кути (Gabor Kuti) и Павел Мачек (Pavel Machek) создали очень упрощённую версию программного засыпания и назвали её swsusp. Я её попробовал и подписался на список рассылки swsusp на Sourceforge. Потом потихоньку начал изучать, как же это работает, и учить C, а потом стал посылать маленькие патчи, чтобы сделать swsusp быстрее, надёжнее и дружелюбнее. Если я правильно помню, у Габора было не очень много времени для разработки, поэтому, естественно, разработкой занимался я.

Примерно в это время Павел добился включения кода в ветку ядра 2.5, но (опять же, если мне память не изменяет) не посоветовавшись с сообществом. Я пробовал работать с Павелом, но ничего не получалось, и наши пути медленно разошлись.

Что касается имени, одна вещь всегда меня раздражала — вот как произносить это «swsusp»?! Поэтому я называл его просто «software suspend». Внезапно мы дошли до точки, когда можно было присвоить версию 1.0 (в июле 2003 года).

Разработка продолжалась, пока мы не выпустили версию 2.0 в конце января 2004 года. Назвали её «suspend2». Разработка Suspend2 продолжилась, но после 2005 года она существенно замедлилась, потому как изменились мои приоритеты, а программное обеспечение стало более зрелым. В последнее время засветился Рафаэль Высоцки (Rafael Wysocki), который захотел назвать программное обеспечение для гибернации как «hibernation», а не «suspend». Чтобы воплотить это желание, я предложил новое имя, так случайно появился TuxOnIce. Мы продолжили нумерацию версий, поэтому текущей является 3.2.

Достаточно ли хорош код управления питанием в Линуксе? Что можно сделать, чтобы его улучшить?

Этому коду предстоит пройти длинный путь развития. Сделано многое, но и сделать ещё нужно тоже очень много, потому как чтобы хорошо управлять питанием, нужно объединять управление питанием «на лету» (т.е., сохранять питание во время использования системы) и управление состояниями системы (засыпание и/или гибернация). Нужно работать с кучей разных архитектур и устройств, нужен гибкий подход, чтобы соответствовать требованиям разных пользователей и разных сценариев работы. Помимо этого, хорошее управление питанием требует не только хорошего ядра, но и хорошо написанных приложений. Лучшую систему управления питанием можно изувечить одной проблемой, например, в плохом цикле опроса событий.

Поэтому вопрос управления питанием — это нечто большее, чем просто маленький вопрос гибернации, над которым я работаю. Это действительно проблема всех.

Но позволь мне думать немного уже и сконцентрироваться на гибернации. Здесь ответ тот же: нет, ИМХО, сейчас код в ядре недостаточно хорош. Я верю в то, что программное обеспечение должно быть надёжным, гибким, дружественным и безбажным настолько, насколько это вообще возможно. Текущий код прошёл длинный путь ещё с первой принятой в ядро версии, но очень много ещё предстоит сделать.

Частично это моя вина. Я не приложил достаточно усилий для продвижения кода TuxOnIce в ядро. Несколько лет назад было стремление рецензировать код для включения его в ядро, но я уже тогда сделал слишком много изменений по сравнению с ядерным кодом. Невозможно, чтобы кто-то его хорошо отрецензировал. Кроме того, я действительно не понимаю, чего от меня хотели или требовали, поэтому я впустую потратил много времени и усилий. TuxOnIce имеет множество ценных функций, которые, как я думаю, следует включить в ядро. Но это необходимо сделать за раз, поэтому нужен кто-то, у кого больше времени, чем у меня. Ну, конечно, Линус может стиснуть зубы и принять TuxOnIce как есть. Хотя я не верю, что такое вообще когда-нибудь произойдёт.

Поэтому, я думаю, что лучшее, что могут сделать люди для улучшения управления питанием в ядре — взяться за дело и помочь. Можно пытаться протолкнуть в ядро TuxOnIce (или его улучшенную версию) либо же улучшать то, что уже в есть ядре. Конечно, быть программистом необязательно — достаточно сообщать нам о проблемах с отдельными драйверами устройств — это тоже очень полезно. Никто из разработчиков ядра не может оттестировать код на каждой конфигурации, поэтому, невозможно исправить неизведанные баги. Просто скажите, если есть проблема, помогите найти причину и попробуйте исправленную версию — это уже будет огромной помощью даже без написания кода.

Что можешь сказать о повышенном энергопотреблении в ядре 2.6.38 (смотри эту статью)?

Увы, ничем не могу помочь, я не слежу за всеми изменениями между версиями. Вообще, могу сказать, что при такой регрессии любой может помочь, используя инструмент git bisect. Главная идея состоит в том, что тестируя, к примеру, ядра 2.6.37 и 2.6.38, мы пробуем половину изменений между версиями и смотрим, есть ли проблема. Если она есть, нужно просто вдвое сузить область поиска между двумя версиями. Так делается несколько раз до тех пор, когда с уверенностью можно сказать: «Этот патч — корень зла». Обычно достаточно 12–16 итераций компиляции и тестирования ядра, но это всё же намного проще и точнее, чем простое угадывание. Короче, погугли «git bisect», там есть хорошие примеры.

Некоторые люди жалуются, что ACPI в Линуксе — причина многих проблем. Что скажешь?

Проблема, с которой столкнулись разработчики открытого программного обеспечения с самого начала его становления — это взаимодействие с закрытым ПО, которое, к тому же, часто плохо написано. В контексте ядра Линукса это значит — помимо всего прочего — взаимодействие с BIOS’ом компьютера. Программисты BIOS — они, как и все программисты, делают ошибки, неправильно понимают спецификации или же вообще читают их как-то по-другому. Иногда проблемы существуют и в самих спецификациях. А это значит, что если чуваки с Intel’а пишут реализацию ACPI для Линукса, она не будет работать, если тупо следовать спецификациям. Им везде придётся играться с обходными трюками. Я не знаю ACPI достаточно хорошо, чтобы сказать, что в его спецификации нет проблем, но из того, что я слышал за последние годы, могу сказать, что большая часть проблем относится не к ACPI, а к различным BIOS’ам и таблицам ACPI, которые написали разработчики BIOS’ов.

Является ли код гибернации в ванильном ядре достаточно качественным? Каковы преимущества и недостатки использования ванильной гибернации?

Как я уже говорил, думаю, что многое нужно сделать для его улучшения. Его основа — стабильна и монолитна, отсутствие необходимости её изменять — большое преимущество. Но есть множество моментов, которые нужно улучшить. Чтобы не быть голословным, назву, к примеру, скорость, которую можно увеличить с помощью — помимо иных методов — введения многопоточной обработки и упреждающего чтения. Также можно прикрутить поддержку обычных файлов (не подкачку), что позволит избежать гонок в условиях нехватки памяти и повысить надёжность (и больше не будет проблем с недостаточным размером хранилища для снимка). Надёжность можно повысить, если сначала проводить вычисления относительно того, хватит ли памяти и ёмкости накопителя для создания атомарной копии (обычно количество необходимой памяти для драйверов вполне предсказуемо). А собственно код можно вынести в модули, чтобы освободить память более нужным вещам в то время, когда гибернация не требуется. Конечно, это никак не задевает настольные компьютеры, но ведь встроенные системы тоже хотят гибернейтиться, особенно если это можно сделать быстро.

Поэтому, код ванильного ядра прошёл долгий путь с того времени, как был включен. Теперь он намного надёжнее и дружественнее. Теперь для него даже BUG_ON()-ы не являются стандартным инструментом отладки!

Может ли Линукс позаимствовать некоторые идеи управления питанием из других (например, BSD) систем?

Я очень давно не запускал BSD, но уверен, что делиться есть чем. Это является мощной силой открытого программного обеспечения, особенно что касается таких маленьких и одиноких разработчиков типа меня. Мы не заботимся о патентах или о том, как же спрятать свои секреты от конкурентов. Мы больше концентрируемся на качестве самого ПО. Поэтому, да, я думаю, что есть идеи, которыми нужно делиться, чтобы в результате пользователям стало лучше, чем было.

Какова цель существования TuxOnIce? Почему ты его разрабатываешь?

TuxOnIce существует, чтобы дать пользователям лучшую гибернацию в Линуксе, которую они могут получить. Я разрабатываю его прежде всего потому, что хочу его использовать, а также потому, что есть куча преданных пользователей, которые заставляют меня его поддерживать и улучшать. Я более чем счастлив от того, что могу что-то отдать сообществу. В конце концов, я использую свободное ПО на моих компьютерах более 10 лет — это честно что-то отдавать взамен.

Ты предпочитаешь выключать компьютер или гибернейтить его? Как часто ты полностью выключаешь компьютер?

Большую часть времени я использую TuxOnIce. Иногда случается, что я пробую swsusp или просто выключаю компьютер, но это скорее исключение, чем правило.

Примерно год назад я купил SSD-диск для ноутбука. Меня поразила разница в скорости. На старом диске скорость чтения и записи была около 100 Мб/с (50 Мб/с — скорость диска, ещё половину прироста скорости давал алгоритм сжатия LZF). При использовании SSD-диска образ записывается на скорости около 250 Мб/с, а читается на скорости 380 Мб/с. На таких скоростях гибернация с 4 Гб ОЗУ не отнимает много времени, а преимущество заключается в том, что после просыпания все запущенные программы и открытые документы появляются снова так, вроде бы компьютер и не выключался. Ну и зачем его вообще тогда просто выключать? :)

В чём разница между ванильной гибернацией и TuxOnIce? TuxOnIce лучше ванильной гибернации?

Эти две штуки разделяют очень много кода. Они делают одинаковые вызовы модели драйверов и следуют одинаковому шаблону заморозки процессов, создавая атомарную копию, записывая её на диск и выключая питание.

Главным отличием является то, что ванильное ядро выполняет однопоточный ввод-вывод, посылая страницы пакетами, в то время как TuxOnIce многопоточен и не использует пакеты. Это увеличивает пропускную способность (конечно, всё зависит ещё и от особенностей «железа»).

Второе существенное отличие состоит в том, что TuxOnIce сохраняет образ в двух частях. Память делится на страницы, которые не будут задействованы при чтении или записи образа (в основном, это страницы процессов и LRU), и все остальные страницы (можно убедиться, что первая часть страниц действительно не задействована, включив вычисление контрольной суммы страниц, что немного увеличит время гибернации). В этом режиме (он включен по умолчанию, но его можно и отключить) TuxOnIce сначала записывает на диск неиспользуемые страницы, потом создаёт атомарную копию оставшихся страниц, копируя их в неиспользуемую память, а также память, используемую первой группой страниц. Потом эта атомарная копия записывается на диск перед выключением. Такой подход позволяет записать полный образ памяти (первая группа страниц обычно значительно превышает по размеру 50% ОЗУ).

С другой стороны, swsusp, создаёт атомарную копию всех страниц, что означает, что максимальный размер образа, который можно записать, составляет 50% ОЗУ. Если всё же нужно записать больше, чем 50%, алгоритм будет освобождать память до тех пор, пока не удовлетворится условие «свободно 50% ОЗУ». На самом деле, он освобождает ещё больше, так как некоторая память требуется и для собственно записи образа.

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

Исторически TuxOnIce был первым по предоставлению большого количества новых возможностей. В нём впервые появилась поддержка SMP, хороший интерфейс пользователя, поддержка файла подкачки, а теперь есть такие вещи, как проверка времени последнего монтирования, чего в ванильной версии нет.

Есть ли какие-нибудь намерения включить TuxOnIce в ядро вместо существующей подсистемы гибернации? Ты пробовал это сделать?

Я бы хотел, чтобы так и случилось, но мой сдвиг приоритетов в последние годы означает, что мне трудно найти для этого время.

Как я уже упоминал, несколько раз возникали идеи отрецензировать код, но в сущности этого не произошло. Так что в будущем нас ждёт постепенное улучшение того кода, что уже находится в ядре. Это большая и длительная работа, но я вижу только такой путь.

Если ванильная гибернация работает нормально, следует ли использовать TuxOnIce? Почему да или почему нет?

Если ванильная гибернация нормально работает, пользуйся ею. Если что-то не устраивает, не бойся попробовать TuxOnIce. Что более важно, держи связь с разработчиками, говори им, что нужно улучшить и почему. Мы не можем исправить проблемы, если не знаем об их существовании.

Сколько разработчиков кроме тебя работает над TuxOnIce?

На протяжении многих лет Бернард Блэкхэм (Bernard Blackham) сотоварищи оказывали мне огромную и неоценимую помощь. Бернард разработал интерфейс пользователя в пространстве пользователя, который до сих пор используется. Другие очень много тестировали TuxOnIce и присылали замечательные отчёты. Но патч на ядро всегда был моим детищем. Много кто присылали патчи, но дизайн, разработка, поддержка и документация — это моё.

Ты делаешь коммиты в ванильное ядро? В каких подсистемах ты заинтересован кроме управления питанием?

Время от времени я делаю коммиты в подсистемы, относящиеся к гибернации, например, в менеджер памяти, но это происходит не очень часто. Я стал хакером ядра только потому, что хотел видеть улучшения в коде, который использую каждый день.

Если пользователи сталкиваются с багами в TuxOnIce, что им следует сделать, чтобы улучшить его качество? Как нужно собирать отладочную информацию, если TuxOnIce падает раз в месяц?

Главное в поиске багов — получить информацию о том, в каком месте возникла проблема. Идеальная ситуация, если возможно выделить проблемную строчку и проблемную конфигурацию. Для этого нужно ядро с отладочной информацией. Когда происходит oops (если он относится к багу), следует записать адрес и с помощью утилиты addr2line после перезагрузки найти строчку, на которой всё рухнуло.

Контекст также важен, поэтому следует получить адреса 4–5 функций из цепочки вызова и также сконвертировать их в названия файлов и номера строк.

Это даст представление о том, какой код привёл к oops’у.

Другая часть картины — описание конфигурации компьютера. Сюда входит конфигурационный файл ядра, который следует прикрепить к багрепорту (есть опция компиляции ядра, которая кладёт конфигурационный файл в /proc/config.gz, её-то я настоятельно рекомендую включить!). Также следует описать, куда сохранялся образ (файл? раздел подкачки? файл подкачки?). Наконец, вывод команды dmesg вообще может быть бесценным.

Лучше по возможности использовать netconsole и интерактивный отладчик TuxOnIce, чтобы получить более детальную картину того, что привело к проблеме. Netconsole может быть полезным для захвата обратной трассировки всех процессов.

Другие полезные инструменты — kdb (особенно с KMS!) и цифровая фотокамера (лучше сфотографировать экран, чем записывать все детали вручную — просто выберите разрешение съёмки, при котором информация остаётся читабельной, а размер файла получается небольшим).

Каким дистрибутивом ты пользуешься? Какое твоё любимое рабочее окружение?

Я — пользователь Ubuntu, главным образом потому, что, в общем, здесь всё просто работает. В качестве рабочего окружения используется xfce4, но с панелью AWN.

Поддерживаешь ли ты включение в ядро таких вещей, как BFS, BFQ, reiser4? Считаешь ли ты позицию Линуса по этому поводу хорошо взвешенной?

В качестве ответа на второй вопрос признаюсь, что понятия не имею, что об этом думает Линус. В отличие от большинства людей в сообществе ядра, я нахожусь как-то снаружи – у меня не карьера программиста (хотя иногда хочется, чтобы было именно так), и я прежде всего пользователь, который хочет быструю, надёжную и частую гибернацию! Прямо сейчас я даже не подписан на список рассылки ядра. На самом деле, я читаю только один список, который не относится к TuxOnIce — по управлению питанием, и то не весь!

А теперь к первому вопросу.

Некоторые проблемы трудно решить, разные подходы качественны по-разному. Кроме того, разные пользователи имеют разные приоритеты в том, что они ищут. Это применимо и к планировщикам, и к файловым системам, поэтому я искренне поддерживаю идею предоставления разных вариантов опций управления в ядре, давая возможность выбирать пользователю. Это один из принципов, реализованный в TuxOnIce. Если посмотреть в /sys/power/tuxonice, можно увидеть множество параметров для настройки под свои нужды, потому как один ботинок на всех не налезет.

Что ты думаешь об изменении нумерации версий ядра?

3.0 обсуждали много лет, я рад, что время наконец-то пришло. Конечно, я хотел бы видеть больше изменений в самом ядре. И ещё я бы хотел, чтобы ядро имело версию 3.0.0. Зачем усложнять жизнь?

Ты сталкивался с багом №12309? Что можешь сказать по этому поводу?

О да, каждый раз при засыпании виртуальной машины в VMware. Я не хочу это комментировать, потому как знаю, что проблемы с планировщиками решаются трудно. Вот что мне нравится в TuxOnIce, так это то, что если всё остальное заморозить, остаётся не так много проблем с планировщиком!

С кем из разработчиков ядра ты знаком лично?

Ну я встречал некоторых из них за последние годы на саммите ядра и на конференциях Linux.Conf.Au, но никого из них не знаю достаточно хорошо. Это всё из-за того, что я не работаю в Red Hat, Intel, Ubuntu или что-то в таком духе.

Я имел удовольствие побывать в Канберре 7 лет назад и немного работать с Расти Расселом (Rusty Russel) и некоторыми парнями, которые были в IBM, но там не было ничего серьёзного и продолжительного.

Какая команда разработчиков открытого ПО лучше всего организована и состоит из профессионалов?

Я работал только с сообществом Drupal (примерно 4 года), но впечатлён тем, как они делают то, что должны.

В каких ещё проектах СПО ты участвовал?

Я участвовал в разработке многих модулей Drupal (Mailfix и Fasttoggle, а также в меньшей степени OG Mailing list) и недавно начал поддерживать форк модуля pam-mysql на Github.

Ты готов к IPv6?

Нет. Я не сведущ в вопросах IPv6, но в будущем нужно будет что-то делать, если адреса таки кончатся. Всё же, я выучу только то, что будет необходимо для того, чтобы эта штука работала. Нельзя знать всего, Google — твой друг! :)

Каково твоё лучшее достижение в жизни?

Гм. Трудный вопрос. Я особо много не думаю о достижениях или о том, что ими нужно гордиться. Я думаю, что следует сказать, что я доволен тем, чем является TuxOnIce — он достаточно стабилен и зрел (хотя проблемы с драйверами и изменения в ванильном ядре означают, что работа есть всегда). Также я счастлив, что имею положительное влияние в семье, церкви и обществе. В конце концов, я думаю, что лучше служить, чем обслуживаться, и если будет возможность оглянуться и посмотреть на жизнь, в которой я так и поступал, то я буду счастлив.

Спасибо за ответы!

Да пожалуйста. Это тебе спасибо за вопросы!