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

> FreeBSD 7-STABLE

> протестировать

А они (пользователи) согласятся ?

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

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

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

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

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

АЧУМЕТЬ!!!

:)

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

это интересно

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

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

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

P.S. Я - Ъ ;-)

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

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

Бвахахахаха.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BSD - R.I.P.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

ыыыыы
ну так и знал!
ты это, ты еще забыл про pf сказать Ж)

Да, забыл, у нас еще есть pf.

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

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

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

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

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

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

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

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

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

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

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

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

>BKL убрали?

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

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

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

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

fixed

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

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

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