From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_06_12 autolearn=no version=3.2.4 Date: Thu, 11 Sep 2008 16:58:25 +0400 From: "Konstantin A. Lepikhov" To: shigorin@gmail.com, ALT Linux kernel packages development Message-ID: <20080911125825.GA20230@lks.home> Mail-Followup-To: shigorin@gmail.com, ALT Linux kernel packages development References: <48C78FA1.20808@altlinux.ru> <20080910105559.GA7447@lks.home> <48C7A8F6.4000007@altlinux.ru> <20080910112936.GA10041@lks.home> <20080910140101.GP26121@osdn.org.ua> <20080910212509.GD26456@lks.home> <20080911085443.GQ25633@osdn.org.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20080911085443.GQ25633@osdn.org.ua> X-Operation-System: ALT Linux Sisyphus (20071221) 2.6.26-wks-pae-alt2 User-Agent: Mutt/1.5.18 (2008-05-29) Subject: Re: [d-kernel] =?koi8-r?b?7s/XwdEg18XS08nRINDBy2XUz9cgc3RkLSo=?= X-BeenThere: devel-kernel@lists.altlinux.org X-Mailman-Version: 2.1.10b3 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 23:33:37 -0000 Archived-At: List-Archive: List-Post: 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.