Search     or:     and:
 LINUX 
 Language 
 Kernel 
 Package 
 Book 
 Test 
 OS 
 Forum 

iakovlev.org

Jens Axboe - Interview 30.01.2007

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: Освободите свой код !
:-)

Оставьте свой комментарий !

Ваше имя:
Комментарий:
Оба поля являются обязательными

 Автор  Комментарий к данной статье