On Sat, Jun 18, 2005 at 03:31:26PM +0400, Konstantin A. Lepikhov wrote:
> > PS: мы тут для одного проекта (мультитредовый сервер) были
> > вынуждены собрать чуточку другое std26-smp с возвёрнутым
> > (после прочёсывания на завязки) на 100 значением HZ.
> > sr@ говорит, что так и не понял, чью светлую голову угораздило
> > влепить туда 1000 и главное -- с какого пере...пугу.  Он же
> > предложил проверить адекватность 250, поскольку по результатам
> > раскопок это вполне нормальный компромисс для ряда применений,
> > где подъём помогает, и ещё одного, где такой оверхед неприемлем.
> пора проверить это с 2.6.12 :)

Вот и я так думаю.  Вчера с vsu@ обсудили, вышло вот что
(также ещё два прилежащих и имеющих отношение к 2.6.12
в свете 2.9.9.9 вопроса, насколько понимаю):

---
<gvy> vsu, ты так и не отозвался на предложение про HZ=250 -- скажи что-нить, или багу для 2.6.12 / #7079 повесить?
<gvy> нам _сильно_ помогло
<vsu> gvy: тут недавно это предложение в lkml прозвучало
<gvy> vsu, о! и-и-и?
<vsu> gvy: как обычно, ругаются
<gvy> vsu, а чем мотивируют "да нафига"?
<vsu> Are you serious?  You're changing the *default* HZ in a stable kernel
<vsu> series?!?
<vsu> This is a big regression, it degrades the resolution of system calls.
<gvy> vsu, если что -- скажи, что тут прошерстили драйверы и пока это похоже на гон
<gvy> бишь думали, что позавязано -- оказывается, нет
<gvy> vsu, ну и в общем от нагрузочной эксплуатации пока впечатления только положительные
<gvy> в общем, IMCO стоит 2.6.12 для 2.9.9.9 собрать именно таким...
<vsu> gvy: так там не драйверы завязаны - скорее, есть некоторое количество старого барахла, рассчитанного на HZ=100
<gvy> vsu, так оно всё равно ломается от 1000
<vsu> gvy: они в первую очередь всякими mplayer и прочими jack мотивируют
<gvy> так что regression IMCO у кого-то в голове. :]
[...]
<vsu> gvy: правда, там какие-то патчи "high res timers" где-то есть в недоделанном виде...
<vsu> gvy: с ними можно и удавить HZ
<gvy> а
<gvy> vsu, насколько помню, mithraen говорил, что ещё в asterisk один из драйверов завязывается
<gvy> надо будет его отпинать, если такую сборку выкатишь
<vsu> gvy: ага - весь realtime от этого опять полетит
<vsu> gvy: разработчики только обрадовались HZ=1000 ;)
<gvy> vsu, :]
<gvy> vsu, по словам sr -- всё-таки 1000 рановато, мож годиков через пару-тройку разве
<gvy> бишь неразумный прыжок сделали, много текущего железа попало в тормоза по скедулеру...
<gvy> PIII всякие
<vsu> gvy: ну дык "на свалку истории" ;)
<henker> vsu: я тут потом пропустил, можно всетаки для usb-device на fat32 пользоваться -o loop, и не выдергивать до окончания IO, или что?
<henker> ой, -o sync, конечно
<vsu> henker: в 2.6.12 - нельзя
<henker> vsu: ок. это пока?
<vsu> henker: оно будет писать в FAT то и дело, чем быстро гробить флешки
<vsu> henker: хрен знает... может, и отвернут опять
<gvy> vsu, :[
<vsu> henker: или ещё какую опцию присобачат
<henker> vsu: vfat наверно? а что у флешки есть ограниченные ресурсы?
<gvy> vsu, а опять же для 2.6.12 в 3.0 это можно как-то... того...? :)
<gvy> henker, циклы перезаписи каждого блока
<henker> gvy: ясенька
* henker flash не будет покупать
<vsu> gvy: там патчей такая куча в том месте намешана :(
<gvy> vsu, а
<gvy> эхх
<gvy> vsu, а 2.9.9.8 сегодняшний (или когда там) на нвидию не встал... они тупо не грузят nvidia.ko
<gvy> правда, его и нету-то в /lib/modules
<gvy> перед второй стадией
<vsu> блин... всё переписали
<vsu> 2563 lines
<vsu> это только fs/fat/
<vsu> gvy: ну ничего... вот с 2.6.12 fglrx так до сих пор и не собирается в нормальном виде
---

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/