Search     or:     and:
 LINUX 
 Language 
 Kernel 
 Package 
 Book 
 Test 
 OS 
 Forum 
 iakovlev.org 
 Kernels
 Boot 
 Memory 
 File system
 0.01
 1.0 
 2.0 
 2.4 
 2.6 
 3.x 
 4.x 
 Интервью 
 Kernel
 HOW-TO 1
 Ptrace
 Kernel-Rebuild-HOWTO
 Runlevel
 Linux daemons
 FAQ
NEWS
Последние статьи :
  Rust 07.11   
  Go 25.12   
  EXT4 10.11   
  FS benchmark 15.09   
  Сетунь 23.07   
  Trees 25.06   
  Apache 03.02   
  SQL 30.07   
  JFS 10.06   
  B-trees 01.06   
 
TOP 20
 Go Web ...611 
 2.0-> Linux IP Networking...363 
 Secure Programming for Li...298 
 2.6-> Kernel 2.6.17...229 
 William Gropp...228 
 Kamran Husain...225 
 Robbins 4...218 
 Advanced Bash Scripting G...214 
 Ethreal 1...209 
 Rodriguez 9...204 
 Rodriguez 6...197 
 UML 3...195 
 Steve Pate 3...193 
 Стивенс 8...193 
 Advanced Bash Scripting G...192 
 Daniel Bovet 2...191 
 Steve Pate 1...189 
 Kamran Husain...187 
 Rodriguez 8...184 
 Kernel Notes...179 
 
  01.03.2019 : 2682145 посещений 

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

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

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

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