Насчёт deadline догадка оказалась верной - для SSD именно он лучше.
По величине кванта времени всё ещё нужна консультация специалистов.

для SSD лучше таки noop.

Да, ну и продолжая разговаривать сам с собой, хочу отметить, что в ArchLinux, как и во всех подобных студенческих поделках (Gentoo, например), как всегда всё сильно через, поэтому их kernelconfig можно брать только за основу для сборки ядра под E3 901

А чем лучше?
Пруфлинк какой-то?

А что Вам мешает собрать ядро и потестить его? Потом отпишитесь.

З.Ы. Мне этот вопрос (насчет частоты прерываний) тоже очень интересен.

http://www.zdnet.com/blog/perlow/geek-sheet-a-tweakers-guide-to-solid-state-d...
http://ubuntuforums.org/showthread.php?t=1041524
ну и вон там еще немного - http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime/

основная мысль -

Random I/O is very hard to deal with, because caching algorithms can’t predict what a host might want for data if it’s random.

The Linux kernel has four different elevators, each with different properties. One of them, noop, is essentially a first-in first-out (FIFO) queue with no extra logic.

т.е. суть в том, что контроллер SSD сам заботится о том когда и куда конкретно скинуть данные и когда их забирать. а noop, всвязи с отсутствием логики по этому поводу, не вносит доп. расходов, и соотв, увеличивается общая производительность IO.

кстати, по поводу тиков - может быть таки лучше будет сделать tickless ?

http://kerneltrap.org/node/6750

100Hz + NO_HZ на ноуте, УМВР.

tickless нужен несколько для другого, как я понимаю: он динамически изменяет частоту таймера во время простоев (там даже пример приведён с полутора секундами). Но к базовой частоте таймера при нормальной загрузке процессора это не относится. То есть если есть базовая частота 300 тиков в секунду, то чаще уже точно не будет. Насчёт дифференциального понижения частоты (200,100) не знаю, если лень поборю, почитаю. Но самое главное - tickless уже есть в официальном ядре, он включен в арчевском конфиге, но tickless никак не зависит от настройки частоты прерывания таймера.

А у арчевского ядра, да и у моего дистрибутивного настройка - 1000 тиков в секунду. Одно дело, когда это мощный процессор, и совсем другое - когда это Intel Atom.

А то, что конфигурируется в ядре, это наверное глобально по дефолту ко всему применяется? Я вот думаю, стоит ли... может, просто echo noop для SSD-шных устройств sda и sdb делать в каком-нибудь скрипте типа rc.sysinit.

>Одно дело, когда это мощный процессор, и совсем другое - когда это Intel Atom.

Во-первых, там все равно no_hz.
Во-вторых, атомы находятся на уровне P4, на которов гоняли 1000 и не парились.

4.2 У арчевского ядра из реп 300Hz:
$ grep HZ /usr/src/linux-2.6.35-ARCH/.config

# CONFIG_RCU_FAST_NO_HZ is not set
CONFIG_NO_HZ=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300
CONFIG_MACHZ_WDT=m

Это их офядро, видимо, а я говорю о сборке специально для EEE PC 901, на которую ссылку дал в 1-м посте.

>Во-первых, там все равно no_hz.

Во-вторых, атомы находятся на уровне P4, на которов гоняли 1000 и не парились.

Да ёлки-палки, no_hz для пауэрсейвинга нужен, для понижения частоты ов время простоя. Насчёт того, что Intel Atom на уровне Pentium IV - сомневаюсь что-то. Формально, может, и на уровне, а фактически даже PIII быстрее был ИМХО. К тому же в лоб и не сравнишь: Atom о двух ядрах, а PIV одноядерный.

я тебе вот что скажу
ставь хоть 100500 - с динтикс пофиг
проверил лично на своём нетбуке с атомом - абсолютно фиолетово с точки зрения батареи, но с 1000 гораздо отзывчивей морда
короче - хозяин барин

>ставь хоть 100500 - с динтикс пофиг
действительно, ТС бред какой-то написал

>This option enables a tickless system: timer interrupts will

only trigger on an as-needed basis both when the system is

busy and when the system is idle.

Как-то так. Только от какой частоты вниз меняет HZ'ы эти динтикс? ;)

Собрал своё ядро, всё работает отлично, вроде даже пошустрее стало (хотя это субъективно конечно), но... почему-то корень монтируется в read-only с упорством, достойным лучшего применения...

Ах да! Ещё почему-то увеличилась предельная громкость звука и стали нормально подключаться наушники, чего до этого не было (звук был тише, а на наушники snd_hda_intel'у было положительно плевать). Понятно, что звуковуха в 901-ом EEE PC - полное г-но, и, кажется, с годами становится ещё и хуже, но... всё равно: пустячок, а приятно.

> и стали нормально подключаться наушники, чего до этого не было

фигасе, что с ядром в арче делают. в бубунте оно еще с древних времен работало нормально (с 8.* емнип, или с 9.04).

хз с какого уровня - прозреваю с X и вниз, где Х - это значение HZ=

isden, вынужден огорчить Вас: это не в Арче с ядром такое делают (вернее, как там я вообще не знаю), а в Mandriva. В Mandriva же издревле уже сложилась добрая традиция: а) патчить ядро хз вообще чем на предмет поддержки оборудования, которое есть аж у одного человека на планете и б) иногда тупить.
Арчевское ядро для eepc-901 тоже было сконфигурено через одно место: несуществующие утсройства, дрова для звуковухи прямо в ядре (они там очень нужны, кто же спорит), нет того самого обработчика события подключения наушников, отсутствие поддержки даже модульной для reiserfs и присутствие - для jfs, шедуллер по дефолту - cfq...
А корневая ФС не монтировалась в rw из-за того, что нет поддержки больших файлов LBDAF я в полном недоумении отправляюсь собирать ядро заново и смотреть, что это за LBDAF такой. Вернее, на системе, где в корне точно нет файлов больше 100Мб всё это довольно странно выглядит.

>The ext4 filesystem requires that this feature be enabled in order to support filesystems that have the huge_file feature enabled. Otherwise, it will refuse to mount in the read-write mode any filesystems that use the huge_file feature, which is enabled by default by mke2fs.ext4.

Ааааа!!!! Бл...ть, ненавижу ext4!!!!

Пофиксил ext4, оказалось, всё очень просто:
mount / -o remount,ro && tune2fs -O ^huge_files /dev/sda1 && fsck.ext4 /dev/sda1 && reboot
Ядро правда классное получилось, ощутил просто даже по разнице в скорости загрузки Firefox'а: видимо, благодаря другому шедуллеру. Удалил пока все диструбивные ядра, ибо нафиг надо. Заодно искренне порадовался тому, что Mandriva по дефолту ставит vbox-guest-additions'ы. Прибил их нафиг. заодно и кое-как накиданные модули в /etc/modprobe.preloa{d,d.d/} тоже поубивал, вместо них добавил стандартный для моего EEE PC 901 список:
nvram
evdev
i2c_i801
dm_snapshot
reiserfs
rt2860sta
tun
psmouse
(tun для OpenVPN нужен, он у меня по дефолту стартует, psmouse внушает подозрения, поскольку его никто не использует, а тачпад при этом работает). Здесь нет модуля для Ethernet'а, поскольку последним я не пользуюсь почти - на то он и нетбук, чтоб по воздуху инет ловить.
Ещё в /etc/modprobe.preload.d/cpufreq оставил модули, хотя вообще вкомпилил performance прямо в ядро и сделал его дефолтным, так что не факт, что другие cpufreq-модули вообще могут быть полезны (и сейчас счётчик их юзания нулевой).

huge_file и LBDAF

столкнулся с аналогичной проблемой, но что интересно - после включения опции CONFIG_LBDAF раздел с ext4 все равно не подключался. Ядро 2.6.35-zen2.
После отключения huge_file все заработало.