[d-kernel] Новая версия пакeтов std-*

[Konstantin A. Lepikhov]

Hi Michael!

Thursday 11, at 11:54:43 AM you wrote:

> On Thu, Sep 11, 2008 at 01:25:09AM +0400, Konstantin A. Lepikhov wrote:
> > Т.е. если у нас обращение к таймеру это low cost запрос, то
> > лучше обращаться к нему чаще.
> 
> Кгм.  Даже я понимаю, что это щёлканье контекстами и,
> следовательно, удар по кэшу.  О каком low cost речь?
См. Documentation/hrtimers/highres.txt:

...
When the timer interrupt happens, the next event interrupt handler is
called from the clock event distribution code and moves expired timers
from the red-black tree to a separate double linked list and invokes the
softirq handler. An additional mode field in the hrtimer structure allows
the system to execute callback functions directly from the next event
interrupt handler.  This is restricted to code which can safely be
executed in the hard interrupt context. This applies, for example, to the
common case of a wakeup function as used by nanosleep. The advantage of
executing the handler in the interrupt context is the avoidance of up to
two context switches - from the interrupted context to the softirq and to
the task which is woken up by the expired timer.

Once a system has switched to high resolution mode, the periodic tick is
switched off. This disables the per system global periodic clock event
device - e.g. the PIT on i386 SMP systems.

Таки получается low cost.

Т.е. для сервера я бы остановился на 250, а для desktop - 1000 (в-прочем,
можно поднять архивы -ck и сделать еще больше).

> 
> > Кстати, в контекте всяких виртуализаций а не тупых полок с
> > deadline наличие высокоотзывчивых таймеров в HN очень даже
> > нужно.
> 
> Это ты так думаешь или кто-то из знающих сказал?
> (не наезд, а апелляция к тестам/опыту)
Это логика - поскольку fairsсhed это гораздо более сложный мозг, чем cfg.

> 
> > > Вот во времена 2.6.10--12 под нагруженной многотредовой
> > > софтиной при HZ=1000 всё проседало вдребезги, сборка с HZ=100
> > > отчасти помогала спасти ситуацию относительно 2.4.9-rhel.
> > > Смутно припоминается, что вешал багу с патчем, сейчас найти
> > > не могу (дело было в 2004--2005).
> > щас я тебе тоже дам презентацию 2006 года где на примере 2.4
> > говорится что липунс фигня по-сравнению с winxp ;) Каких еще
> > скелетов в шкафу поворочаем?
> 
> Это, ты со статьёй 2002 года мог бы скелетов и не упоминать ;)
> 
> > > > > Сам же убеждал меня слить всё в один image.
> > > Это я, наверное, убеждал -- что сторадж нельзя выносить
> > > вообще, а популярные сетевые карты -- "не стоит" (иначе
> > > никакой сетевой загрузки, в т.ч. установки).
> > Нельзя выносить потому что нельзя и потому что не умеем?
> 
> Да, конечно.
> 
> > В последнем контексте если запатчить package management и
> > mkinird то "не вижу препятствий". 
> 
> У нас более простые патчи на mkinitrd годами проходили...
> поэтому сперва следует продумать и решить это "если" (над чем
> мы с led@ уже думали и не раз), а затем возвращаться к вопросу
> порезки ядра (каковой в том же контексте я ещё с nidd@ обсуждал,
> когда он рисовал изначальную kernel policy).
Вы тупите :) Макет как это можно сделать у нас почти готов, осталось
запатчить mkinitrd/rpm и проверить.

-- 
WBR et al.