Jens работает с линуксом с 93-го года.
Ему 30 лет , он живет в копенгагене , работает на Оракл.
В версии 2.5 кардинально переписал block layer и поддерживает его сейчас.
Интересы его связаны преимущественно с IO , он реализовал несколько новых
IO-шедулеров ядра, включая базовый CFQ, или Complete Fair Queuing scheduler.
В этом интервью Jens рассказывает,как он стал майнтейнером block layer
и других блочных устройств.
Он предлагает нам глубже взглянуть на текущий статус CFQ.
Он дискутирует по поводу процесса разработки текущей версии ядра,
обьясняет , почему GPL - это важно.
Q: Пожалуйста,расскажите о себе.
A: Я живу в копенгагене с женой и 2-летним сыном.
Мне 30,я работаю на Оракл,что очень хорошо коррелируется с моей
текущей работай над ядром.Перед этим я работал в SUSE.
В основном я работаю дома,хотя и случаются набеги в оффис.
Я до сих пор студент универа , но похоже так его никогда и не закончу - я слишком занят :-)
Q: Работа в Оракле как-то определяет вашу специализацию ?
A: Вообще-то нет.Просто так получилось,что те вещи,которыми я занимался,
оказались важны для работы Оракла под Линукс.
Конечно,это совпадение повлияло на выбор моей работы.
Вообще,Оракл очень лояльно относится к тем людям,
которые конкретно работают над ядром,и все они находятся в ветке Линуса.
Q: Когда вы познакомились с Линуксом ?
A: Я узнал о нем из прессы , тогда меня заинтересовало сравнение его с OS/2.
Это было статья в пятничном номере.
Перед этим я программировал в Turbo C под DOS,для него были актуальными
проблемы с сегментацией,и тут появляется реальная 32-битная операционная система.
Это было в 93-м,и получить Линукс можно было тогда только через шведскую почтовую службу.
У меня не было даже денег,чтобы позвонить туда.
По счастью , я нашел подержаный сидюк , и спустя несколько недель экспериментов
я-таки инсталлировал линукс.После чего пути назад в дос уже не было :-)
Q: Какая это была версия ядра ?
A: Это была версия 0.99. Я долго возился с загрузкой,
потому что ядро не признавало мой сиди-привод.
Тогда я впервые узнал,что такое kernel panic :-)
Q: Что вы делали тогда в Линуксе ?
A: Программировал,конечно.Я познакомился с юниксовой файловой системой.
Это была работа нового уровня.
Помню,я пропустил несколько дней в школе-за это время я успел заставить работать DOSEMU.
Ночи напролет я собирал и компилировал иксы.
Притяжение линукса в том , что он прозрачен,там нет никаких ограничений
на эксперименты с системой.
Если падала 3-я винда , диагностика падения была крайне тяжела.
В Линуксе все намного проще.
Q: Вы - майнтейнер Linux Kernel block layer. Что это такое - Linux Kernel block layer ?
A: block layer - это код , который связывает блочные устройства (диски,си-ди-ромы и т.д.)
и файловую систему.Он помогает драйверам управлять ресурсами.
В него в частности входит IO scheduling.
Работая над ядром 2.5 , я его полностью переписал.До этого он был безобразно написан.
Он неадекватно вел себя в случае с несколькими ЦПУ,не поддерживал highmem IO,
был очень ограничен в ресурсах.Переписав его, я и стал майнтейнером.
Впервые он появился в версии 2.5.0.
Поддержка его-дело достаточно хлопотное.Он постепенно перетягивает
на себя функциональность многих драйверов , таких как SCSI например.
Задача заключается в том,чтобы уменьшить сложность и размер самих блочных драйверов устройств.
Чем проще драйвер-тем меньше проблем.Получить багу в block layer намного сложнее , чем в каком-то
драйвере,ведь драйвера пишут сейчас все кому ни лень :-)
Q: Кто занимался поддержкой block layer до версии 2.5 ?
A: А конкретно никто.В самом начале Линус написал ll_rw_blk.c , а потом разные люди
делали заплаты на этот код.Все это надо было переделывать.
Q: Что можно сказать о связи файловых системах Reiser4,ZFS и block layer?
A: О них конкретно пока ничего. Если взять XFS, то она захватывает большую порцию данных block layer.
На конференции SGI заявила о том, что у нее не было проблем даже при 10GiB/sec IO.
Q: Вы выпустили несколько патчей,которые делают явную plugging вместо неявной plugging.
Чем они отличаются?
A: Основную разработку вел Nick Piggin,который сейчас перешел на vm.
plugging-это некая предварительная работа перед тем,как обработать поток данных от устройства.
Это можно сравнить с тем,как вы в ванную вставляете пробку,и вода прекращает вытекать до тех пор,
пока вы пробку не удалите.Это уменьшает количество запросов IO к устройству и улучшает работу шедулера.
Это благоприятно действует на дисковые устройства.
Вы как-бы временно отключаете драйвер и можете заниматься обслуживанием других устройств,
а не только его одного.
Q: Недавно была дискуссия на LKML по поводу использования флага O_DIRECT при открытии файлов.
Что вы об этом думаете?
A: O_DIRECT - это очень быстро.Но проблема в его нонешней реализации.
Дело в том,что при этом кешируется буффер IO,а это неверно.
Нужно пользовательские данные мапировать в ядро.
Q: Вы также являетесь майнтейнером таких драйверов , как
IDE/ATAPI CD-ROM driver, SCSI CD-ROM driver, uniform CD-ROM driver.
Как это произошло и каких усилий это стоит ?
A: Драйвер CD-ROM - этоо первое , что я сделал в линукс.
Дело в том,что предыдущий разработчик отошел от дел и искал добровольца.
А для меня это было очень интересно в образовательных целях.
Я расширил uniform CD-ROM layer(cdrom.c) ,добавил поддержку для дивиди,
Сейчас я немного отошел от этого.
Q: В сентябре 2002 вы выпустили патч "deadline" I/O scheduler, который сразу попал в стабильную ветку.
Чем этот шедулер отличался от предыдущего?
A: В версии 2.4 IO шедулер был старым,он плохо настраивался.
Я предложил новую версию,которая была построена на принципах CSCAN,
с использованием двойного связного списка.
Каждый запрос теперь ограничивался по времени,и все запросы ложились в список.
Тем самым мы разгрузили устройство,которое было занять чем-то другим в момент запроса.
Q: А нельзя ли немного подробнее о 2.4 IO scheduler ?
И что это за "elevator"?
A: elevator - или лифт - это классический алгоритм IO scheduling.
Он обслуживает дисковый сервис в обоих направлениях.
В версии 2.4 IO scheduler работал именно по этому принципу.
Главная проблема у него в том,что IO запрос,который находится не в голове списка,
может очень долго ждать,когда его начнут обслуживать.
Q: Что вы сделали для оптимизации работы шедулера ?
A: Алгоритмы шедулятора - это необычайно увлекательная вещь,
и мне нужно было придумать что-то принципиально новое,
чтобы реально изменить уже существующую модель.
До этого я работал над драйвером CDROM , и мне было интересно -
а что же творится на уровень выше драйвера ?
Когда тебе нужно сделать какой-то реальный фикс ,
это знаете-ли , здорово мотивирует.
Q: Благодаря вам,мы теперь имеем возможность выбрать планировщик.
Сколько IO шедуляторов вообще на данный момент в ядре и чем они различаются?
A: В данный момент ситуация такова,что мы можем изменить поведение планировщика -
для этого даже не нужно перезагружаться.
Его можно переконфигурировать в подгружаемом модуле.
На данный момент в ядре 4 шедулера : базовый "noop" , который ничего не делает.
Он просто выставляет запросы в очередь в порядке FIFO.
Следующий - deadline - который я уже описывал.
Он обслуживает приложения с критическим временем ожидания.
И еще 2 шедулера - "anticipatory" и "cfq".
"anticipatory" основан на deadline , он занимается сериализацией чтения данных
каким-то определенным процессом и позволяет устройству "отдыхать" на короткие промежутки времени.
"anticipatory" обеспечивает хорошую пропускную дисковую способность для раздельных
рабочих нагрузок IO.
Ограничения есть у всех четырех.
Вообще IO шедулер по умолчанию вполне обслуживает любые запросы для большинства приложений,
но если у вас приложение с интенсивной IO-нагрузкой , эксперименты в данном случае
с вариантами планировщика могут иметь свой эффект.
Q: Есть ли какой-то риск при смене IO scheduler ?
A: Если бы он был , мы бы это сразу заметили.
При изменении IO планировщика происходит следующее:
сначала все равно будут обслуживаться запросы по умолчанию,
и только после этого произойдет переход на новую очередь добавленного планировщика.
Там все довольно хитро сделано.
Q: В феврале 2003 вы обнародовали 2 новых IO планировщика :
Stochastic Fair Queuing (SFQ) scheduler и
Complete Fair Queuing (CFQ) scheduler.
Что подвигло вас на доработку уже существующего deadline scheduler?
A: deadline не умел подстраиваться под индивидуальные особенности конкретного процесса.
SFQ с самого начала имел отношение к сетевым алгоритмам.
Основная задача заключалась в разбиении потока пакетов на мелкие части и их хэширование.
Q: CFQ scheduler был введен в ядро 2.6.6 в апреле 2004.
Почему он пришел на смену SFQ ?
A: Основное отличие в том , что CFQ ориентирован на конкретный процесс.
Он позволил избавиться от т.н. проблемы коллизии хэширования пакетов.
CFQ - это улучшенный вариант SFQ.
Да и появились они на свет почти одновременно.
Q: Каков текущий статус CFQ scheduler?
A: На текущий момент имеем 3-ю версию.
3-я инкарнация работает начиная с 2.6.13.
В нем используется принцип time slice , аналогичный тому ,
который используется в планировщике процессов.
Классические шедулеры не очень хороши для распределенных нагрузок.
Примером этого является редактирование файла,который в этот момент сохраняется
на диск другим процессом.
Другой пример - когда один файл читают несколько процессов.
CFQ дает прирост производительности в таких случаях до 30-50MiB/sec по сравнению
с 1MiB/sec в старых вариантах.
CFQ в основном устаялся,но подвергается изменениям применительно к новым аппаратным средствам.
У него появляются такие фичи , как приоритет .
В дистрибутивах SUSE и Red Hat CFQ стал де-факто начиная с 2.6.18.
Q: Какие принципиальные улучшения были достигнуты в последней версии CFQ scheduler?
A: Текущая версия достаточно стабильна и хорошо работает для различных нагрузок
и аппаратных средств.
Но есть над чем поработать.
Например , никогда нельзя сказать с определенностью,
как себя будет вести то,что находится с той стороны дискового контроллера-
ведь это может быть не один диск , а целый дисковый массив.
Q: Какие улучшения вы запланировали для себя на будущее ?
A: Я планирую сделать полный анализ того, как CFQ взаимодействует с устройствами,
для того чтобы оптимизировать и лучше управлять очередью команд.
Так , второй SATA уже пришел на десктоп.
Также нужно улучшить кооперативнцю работу нескольких задач,
которые одновременно работают над одной областью диска.
Так что работать и работать.
Q: Можно поподробнее о последнем ?
A: Одно из преимуществ CFQ - в том,что он хорошо работает с синхронными дисковыми запросами.
Если несколько задач трудятся над одним дисковым сектором-
имеет смысл разделить время между ними.
Рассмотрим пример :
$ find . -type f -exec grep somepattern '{}' \;
В этой команде мы циклично форкаем грепы.
У текущего CFQ с этой командой проблемы,поскольку grep , когда выходит,
становится неуправляемым,и очередь начинает тормозить.
Q: Расскажите о ionice и о том,как CFQ управляет процессами в разрезе
различных уровней планировщиков ?
A: CFQ - это дерево очередей, где каждый процесс имеет линк на 2 очереди - private и async.
Вторая расшарена между процессами,которые выполняются в одном уровне приоритета.
Первая управляет синронизированными запросами для конкретного процесса.
Когда процесс начинает обращаться к диску,он инициализирует time slice,
в течение которого будет иметь приоритетный доступ к диску.
Этот промежуток может меняться в зависимости от других процессов в очереди,
и более приоритетные будут обращаться к диску более часто.
Уровни приоритета можно разделить на 3 класса - idle, best-effort, real time.
Процессы из первого уровня будут обслуживаться только тогда,
когда диск вообще не используется.
Второй уровень приоритета - он по умолчанию.
Процессы с этим приоритетом обслуживаются по алгоритму round robin.
Процессы третьего уровня получают доступ к ресурсам моментально,
как только это необходимо.
Это такая общая картина того , как CFQ управляет приоритетами.
Q: Какие настройки имеются у CFQ scheduler ?
A: Это протяженность time slice,установка expiration time для новых запросов FIFO,
а также возможность изменить однонаправленность дисковых операций,как бы позволяя
диску делать перемотку назад.Но изменение этих настроек вовсе необязательно
для улучшения производительности.
Эти настройки можно найти в sysfs.
Например,для изменения настроек sda смотрите /sys/block/sda/queue/iosched/.
Q: Вы работаете над ядром уже довольно долго.
Насколько изменилась ваша роль в этом проекте за это время
и как вообще меняются люди ?
A: За это время число основных майнтейнеров увеличилось,потому что увеличилось
вообще количество людей , которое работает над ядром.
Не думаю,что люди за это время сильно изменились.
Кого-то мы теряем,кто-то приходит,кто-то перемещается в другие плоскости ядра.
Вообще можно сказать,что народ стал более зрелым что-ли.
Q: Можно ли сказать,что ядро в каких-то аспектах уже полностью устоялось,
или оно постоянно развивается ?
A: Процесс этот идет уже много лет,и я не вижу,чтобы он замедлился- скорее наоборот.
Я думаю,что ближайшие 5 лет тенденция сохранится.
Ведь аппаратные средства не стоят на месте,поэтому и для нас всегда будет работа.
Q: Как использование бит-кипера вляиет на процесс контроля и разработки ядра ?
A: Сейчас это не так сильно,как кажется.Основные изменения в управления кодом уже прошли
несколько лет назад.
Это реально помогает,потому что помогает понять причины проблем там,где мы раньше делали
с помощью diff. Бит-кипер позволяет работать с различными ветвями.
Он позволяет управлять рассылкой патчей.
Q: Как вы думаете,скоро мы увидим версию 2.7 (или 3.0) ?
Думаю,это не скоро произойдет.Линус сказал,что версия 2.7 появится тогда,когда кто-нибудь
возьмет управление проекта в свои руки. И что-то пока не видно желающих.
Нонешняя модель разработки работает,на мой взгляд достаточно хорошо.
И пока еще нет нужды в новой версии.
Q: Остается ли версия 2.6 по-прежнему стабильной,несмотря на свой срок развития ?
A: Я думаю,да.
Была проделана очень серьезная стабилизационная работа.
В версии 2.4 все было немного по-другому - там было очень сложно разобраться с ветками ядра.
Их одновременная поддержка занимала очень много сил.
В 2.6 работа над ядром стала более распределенной и дифференцированной.
Q: Насколько для вас важно то,что ядро выпускается под лицензией GPL ?
A: Я не политик,но GPL-это очень важно.
Причина,по которой я пришел в опен соурс,в том,что знания становятся общедоступными.
Мне нравится делать свои идеи публичными,и мне нравится,что также поступают и другие.
GPL - это больше чем лицензия.
Q: Что вы можете посоветовать читателям,которые хотят стать разработчиками ядра?
A: Подпишитесь на Linux kernel mailing list и найдите проекты,которые интересны для вас.
Здесь необходима личная заинтересованность.
Изучение ядра дает очень много в плане развития.
Нужно просто окунуться и решить какую-то проблему.
Q: Что бы вы хотели сказать на прощание ?
A: Освободите свой код !
:-)
LINUX 
Kernels
