LINUX.ORG.RU

Во FreeBSD появился «упреждающий» дисковый планировщик

 , ,


0

0

Luigi Rizzo предлагает пользователям FreeBSD 7-STABLE протестировать новую инфраструктуру для реализации внешних планировщиков ввода-вывода дисковой подсистемы, построенную на базе системы GEOM.

В качестве демонстрации возможностей системы, представлен планировщик, реализующий алгоритм "anticipatory scheduling". С целью уменьшения перемещений головок по диску планировщик пытается упорядочить поступающие запросы для более последовательного обращения к диску, вводя небольшую дополнительную задержку (2..5мс) перед фактической отправкой запроса и объединяя поступившие за это время новые запросы с ожидающими в очереди.

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

Взято с opennet.ru

>>> Подробности

★★★★★

Проверено: Shaman007 ()

> С целью уменьшения перемещений головок по диску планировщик пытается упорядочить поступающие запросы для более последовательного обращения к диску

Софтверный NCQ?

Manhunt ★★★★★
()
Ответ на: комментарий от u5qh

Тогда потренируются на пользователях карента. :)

Lumi ★★★★★
()

А что раньше во фре медленно работала дисковая подсистема? Зафига эти планировщик писать и переписывать по сто раз. Вон в линукс уже сто планировщиков процессов понаделали и кому они нужны? Лучше бы эти силы на полезное дело потратили.У опенсорс не так много грамотных программистов, а они все время тратят на ерунду. С другой стороны здесь каждый делает то, что хочет, а жаль...

anonymous
()

Процитирую Викторию Прутковскую:

АЧУМЕТЬ!!!

:)

a110c
()
Ответ на: комментарий от Khades

>скорости такого плана никогда мала не бывает:)

С этим я согласен! Но зачастую проигрыш в той самой скорости оказывается уровнем выше. Куча софта, написанного неграмотными программистами, скушает все эти небольшие преимущества!!! То есть люди просто блох вылавливают на мой взгляд.

anonymous
()
Ответ на: комментарий от anonymous

Я правильно понял? Если новый планировщик собираются прикручивать к stable, то в current он уже давно есть? Или это опечатка насчёт stable?

P.S. Я - Ъ ;-)

Cancellor ★★★★☆
()

> Во FreeBSD появился "упреждающий" дисковый планировщик

ну все, теперь линупсу точно капец!

anonymous
()

интересная штука, правда с весьма узкой специализацией. мне кажется, что это не очень перспективная технология, т.к. скоро доделают харды на триггерах http://www.lenta.ru/news/2009/01/06/nec/ и, даже flash будет не нужна, ибо дорога и недолговечна.

OzOx
()

А вот и да! Оптимизировать скорость работы с диском ИМХО гораздо умнее, чем оптимизация шедулера в ведре. всё-таки кеш он пока на харде валяется. во всяком случае у меня. Рано или поздно, но любая программа упирается в диск и начинает ТОООООРМОЗИИИТЬЬЬ.

anonymous
()
Ответ на: комментарий от OzOx

> мне кажется, что это не очень перспективная технология
Только почему-то часто anticipatory делают планировщиком ввода/вывода по умолчанию. В GNU/Linux, по крайней мере ;-)

anonymous
()

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

black7
()

А зачем ждать целых 2..5 мс? И вообще зачем задержка, если есть read ahead + delayed write? (боюсь стать троллем, но, надеюсь, это в bsd есть). Да и даже если read ahead нет либо оно в задаче неэффективно, то как принудительный sleep() в потоке, вызвавшем read() поможет сгруппировать два запроса от однопоточного приложения?

Где бы про это почитать наглядно и доступно?

alexsaa
()
Ответ на: комментарий от anonymous

>А что раньше во фре медленно работала дисковая подсистема?

что школьник-кун, тебя зачали в 90-х и ты не застал 3.х и 4.х?

>в линукс уже сто планировщиков процессов понаделали и кому они нужны?

людям нужны. в отличии от тебя. ты только в биореактор годишься

>С другой стороны здесь каждый делает то, что хочет, а жаль...

жаль что есть свобода? ну так бегом вали на урановые рудники

black7
()
Ответ на: комментарий от anonymous

> А что раньше во фре медленно работала дисковая подсистема?

Не самая сильная сторона фри, так скажем.

anonymous
()
Ответ на: комментарий от anonymous

все-же померяйте, прежде чем. есть такой пакет bonnie.

по попугаям таки да, xfs и ext3 шустрее. но при этом загрузка проца 80-90%% с копейками.

у ufs2 попугаи несколько скромнее, но и загрузка проца не вызывает омерзения.

Видимо можно подтюнить попугаи, только зачем.

мне не нравятся замирания системы при интенсивных дисковых операциях.

ккапча seeburn. жжоте!

anonymous
()
Ответ на: комментарий от frost_ii

> SSD уже повсюду.

По ряду параметров SSD пока вдрызг сливают традиционным HDD. Сходу могу назвать два: 1. по допустимому числу перезаписей 2. по соотношению цена/мегабайт

Manhunt ★★★★★
()
Ответ на: комментарий от frost_ii

> С добрым утром! SSD уже повсюду.

Как там у SSD со скоростью записи?

anonymous
()

Новый "anticipatory scheduling"! Теперь и в BSD.

В планах разработчиков выпустить тестовую поддержку многопроцессорности в течении двух лет.

ttnl ★★★★★
()
Ответ на: комментарий от ttnl

> В планах разработчиков выпустить тестовую поддержку многопроцессорности в течении двух лет.

Подколка немного запоздала :) Они многопроцессорность активно пилить начали в пятой версии, а сейчас уже седьмая. В 7.1 у них даже ULE по дефолту включен.

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

> Софтверный NCQ?

во фре нет поддержки и хардварного NCQ. Читай ata(4):
NOTES
     ...
     Native Command Queuing (NCQ) on SATA drives is not yet supported.

anonymous
()
Ответ на: комментарий от anonymous

>мне не нравятся замирания системы при интенсивных дисковых операциях.

JFS+2.6.26-rt9 никаких проблем с этим
Reiser4-gzip1+Zen-2.6.29-чтототам, то же самое. ЧЯДНТ?

devl547 ★★★★★
()
Ответ на: комментарий от devl547

>JFS+2.6.26-rt9 никаких проблем с этим
>Reiser4-gzip1+Zen-2.6.29-чтототам, то же самое. ЧЯДНТ?

юзаешь нестабильный дистр или какой нибудь ахтунг ->gentoo<-

theurs ★★
()
Ответ на: комментарий от anonymous

Сейчас придет iZEN и докажет, как сильно ты ошибался.

EmStudio
()
Ответ на: комментарий от aspell

ну все
счаз тут нарисуются iZen, lissyara и иже с ними, и будут всем рассказывать какое УГ этот наш линукс :)

anonymous
()
Ответ на: комментарий от aspell

>Все, что делается во FreeBSD, делается ко благу.

И заранее предупреждая все выкрики про отваливающиеся ядра, флешки, малое кол-во поддерживаемого оборудования и т.д., - да, и это тоже.

aspell
()

>Во FreeBSD появился "упреждающий" дисковый планировщик

Он сразу планирует место под аниме!

Byron
()
Ответ на: комментарий от Gharik

>Anticipatiory появился, не пройдёт и ста лет как появятся дедлайн и цыфка :)
>Gharik


Долбозвонам объяснять бесполезно ... но я все же попробую :)
Понимаешь - топик это не сам планировщик а фреймворк для изготовления онных - каких душа пожелает :) Но "упреждающий" - "из коробки" :)

anonymous
()
Ответ на: комментарий от anonymous

>счаз тут нарисуются iZen, lissyara и иже с ними, и будут всем рассказывать какое УГ этот наш линукс :)

Линукс - не УГ, а так, слабое говнецо. Отваливающийся HAL, неработающий NM, глючное ядро состоящее из грязных хаков и детских заплаток чуть более чем полностью, эксперементальные фишки на протяжении всего существования 2.6 и жыыыыыыыыр. Много бесполезного жыра, которое и называется Линукс. Я на 2.4 сидел и все было ОК, но технологии рвутся вперед, а 2.6 оказалось такой упоротой кровавой какахой, что я быстро смылся на БЗДю. И не жалею, надо заметить.

aspell
()
Ответ на: комментарий от aspell

ну че, сидел бы и дальше на 2.4 оно ж == freebsd 7.1 Ж) только не нужно мне дифирамбы тут петь про zfs, окей?

anonymous
()
Ответ на: комментарий от anonymous

eill@notebook:/sys/block/sda/queue$ cat scheduler
noop anticipatory deadline [cfq]

что я делаю не так?

gr_buza ★★★★
()

Они с ума сошли, это проблемы железа.

В ряде случаев от таких пионеров будет только хуже. пример: ссд.

А на хардах давно такое есть.

ChALkeR ★★★★★
()
Ответ на: комментарий от ChALkeR

>> Головки... По диску... А ничего, что у меня еее с 40 гигами флэша и там нет головок?


ключевая фраза здесь "для реализации внешних планировщиков ввода-вывода дисковой подсистемы" мне кажется... значит будет выбор. ну прям как в линукс ;)

anonymous
()
Ответ на: комментарий от anonymous

>ну че, сидел бы и дальше на 2.4 оно ж == freebsd 7.1 Ж)

Ага, конечно. Только вот поддержка нового оборудования и т.д. К тому же 2.4 умеет наполнять /dev только при помощи какого-то говноdevfs или как его там?

>только не нужно мне дифирамбы тут петь про zfs, окей?


Надо, надо, еще как надо. У нас есть поддержка ZFS и DTrace, хотя я не знаю нахрен оно мне нужно, но все же :)

aspell
()

Он загонит фрю обратно, в могилу?

Quasar ★★★★★
()
Ответ на: комментарий от aspell

Когда мозг появится, приходите.

З.Ы. мозг нужен, чтобы за зря не "срать в каментах"

sdio ★★★★★
()
Ответ на: комментарий от anonymous

> Долбозвонам объяснять бесполезно ... но я все же попробую :)
> Понимаешь - топик это не сам планировщик а фреймворк для изготовления онных - каких душа пожелает :) Но "упреждающий" - "из коробки" :)


Ты прав: лучший способ самом понять проблему - это объяснить её суть другим.

А во фре треды есть? BKL убрали? Выгрузку модулей отладили? о_О

Gharik
()
Ответ на: комментарий от ChALkeR

>Головки... По диску... А ничего, что у меня еее с 40 гигами флэша и там нет головок?

Уровень GEOM уже давно забил на наличие каких-то там головок (коих может быть 256), цилиндров и секторов на цилиндр. Всё это — бессмысленная "туфта", которая не имеет ничего общего с истинными параметрами быстродействия физического носителя — внутри носителя всё равно они пересчитываются в собственную систему адресации. Тем не менее, эта "туфта" до сих пор используется для логической адресации единиц пространства любого носителя от HDD и SSD до USB-брелков.

Запомните: GEOM не оптимизирует запросы на физическом уровне доступа к диску. Этим занимаются драйвера, которые более-менее сведущи в свойствах физического носителя. И то не всегда в случае с generic SCSI - da(4).

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

iZEN ★★★★★
()
Ответ на: комментарий от Gharik

>А во фре треды есть?

libthr(3) -- 1:1 POSIX threads library.

>BKL убрали?


GIANT Lock убрали в сетевой подсистеме. Сейчас чистят оставшиеся части.

>Выгрузку модулей отладили? о_О


А что, при # kunload linux.ko система разве висла?

iZEN ★★★★★
()
Ответ на: комментарий от aspell

> что я быстро смылся на венду. А бзду держу, чтоб в ней поковырятья. И не жалею, надо заметить.

fixed

Demon37 ★★★★
()
Ответ на: комментарий от ChALkeR

твой выбор none :)

некоторые конечно и с этим несогласны...

А вообще минимизация перемещения головок по диску это прежде всего долговечность механики этого самого диска... Как сейчас помню за месяц дедлайн планировщик выкосил старые (+5 лет) диски на сквиде (правда и было повышение производительности отмечено)...

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.