[sisyphus] КЮ. Часть 2

[sisyphus] КЮ. Часть 2

[Anton Gorlov aka stalker]

Здравствуйте, ALT.

На opennet сегодня прочитал:

----------------
После того как Kenneth Chen, сообщил о результатах тестирования
Linux ядер 2.6.x, которые вскрыли неоднородность производительности
различных версий ядер серии 2.6 (например 2.6.11 оказалось на 13%
медленнее ядра используемого в RedHat Enterprise 3, 2.6.9 на 6%, а 2.6.8 на 23%),
Linus Torvalds принял решение производить автоматизированное ежедневное тестирование
производительности всех выпускаемых предварительных версий ядер.
-----------------


Оно действительно тормоз?

-- 
С уважением,
 Anton                          mailto:pnz37@mail.ru

Re: [sisyphus] КЮ. Часть 2

[Boldin Pavel]

Anton Gorlov aka stalker пишет:

>Здравствуйте, ALT.
>
>На opennet сегодня прочитал:
>
>----------------
>После того как Kenneth Chen, сообщил о результатах тестирования
>Linux ядер 2.6.x, которые вскрыли неоднородность производительности
>различных версий ядер серии 2.6 (например 2.6.11 оказалось на 13%
>медленнее ядра используемого в RedHat Enterprise 3, 2.6.9 на 6%, а 2.6.8 на 23%),
>Linus Torvalds принял решение производить автоматизированное ежедневное тестирование
>производительности всех выпускаемых предварительных версий ядер.
>-----------------
>
>
>Оно действительно тормоз?
>
>  
>
Да нет, :) если пересобрать под свою машину - очень даже ничего...

кстати, ALT, вам _действительно_ нехватает макросов к RPM которые бы 
собирали ядро с оптимизацией под машину (драйвера built-in и т.д.) на 
лету (без участия пользователя)

набрал
rpmbuild --rebuild kernel-image-opt26....

и оно само определило железо и все остальное... вот так :)

Re: [sisyphus] КЮ. Часть 2

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

On Sat, Apr 02, 2005 at 03:04:29AM +0500, Boldin Pavel wrote:
> кстати, ALT, вам _действительно_ нехватает макросов к RPM которые бы 
> собирали ядро с оптимизацией под машину (драйвера built-in и т.д.) на 
> лету (без участия пользователя)
Интересная идея ;))

> набрал
> rpmbuild --rebuild kernel-image-opt26....
> и оно само определило железо и все остальное... вот так :)
Не, чтоб конвертить всякие pciscan в конфиги ядра - это не знаю, какой ИИ
нужен :( Из-за разнообразия как железа, так и конфигов...

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

>жаль, что ALT пока не выпустил наружу AMD64 репозитарий сизифа...
Этим занимается мышь. Не та, о которой речь пойдет ниже, а mouse@
:)
		-- horror in community@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] [JT] ядро самонастраивающееся, с неонкой унутре (was: КЮ. Часть 2)

[Michael Shigorin]

On Sat, Apr 02, 2005 at 03:04:29AM +0500, Boldin Pavel wrote:
> кстати, ALT, вам _действительно_ нехватает макросов к RPM
> которые бы собирали ядро с оптимизацией под машину (драйвера
> built-in и т.д.) на лету (без участия пользователя)

Это _Вам_, может, не хватает.  Нам, видимо, хватает или облом
заниматься ...эээ... этим.

Если есть такое непреоборимое желание раскладывать перед своей
системой грабли на ближайший апгрейд или сдыхание мамки -- вперёд
и с песнями, дорогой Леонардо. :)

PS: no offence but no joke altogether :)

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

Re: [sisyphus] КЮ. Часть 2

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

On Sat, Apr 02, 2005 at 03:04:29AM +0500, Boldin Pavel wrote:
> кстати, ALT, вам _действительно_ нехватает макросов к RPM которые бы 
> собирали ядро с оптимизацией под машину (драйвера built-in и т.д.) на 
> лету (без участия пользователя)
Интересная идея ;))

> набрал
> rpmbuild --rebuild kernel-image-opt26....
> и оно само определило железо и все остальное... вот так :)
Не, чтоб конвертить всякие pciscan в конфиги ядра - это не знаю, какой ИИ
нужен :( Из-за разнообразия как железа, так и конфигов...

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

>жаль, что ALT пока не выпустил наружу AMD64 репозитарий сизифа...
Этим занимается мышь. Не та, о которой речь пойдет ниже, а mouse@
:)
		-- horror in community@

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Re: КЮ. Часть 2

[Konstantin A. Lepikhov]

Hi Boldin!

Saturday 02, at 03:04:29 AM you wrote:

> Да нет, :) если пересобрать под свою машину - очень даже ничего...
однако. А если самому написать (зачем доверять каким-то пионерам), то еще
лучше ;)

> 
> кстати, ALT, вам _действительно_ нехватает макросов к RPM которые бы 
> собирали ядро с оптимизацией под машину (драйвера built-in и т.д.) на 
> лету (без участия пользователя)
> 
> набрал
> rpmbuild --rebuild kernel-image-opt26....
> 
> и оно само определило железо и все остальное... вот так :)
зачем?

-- 
WBR, Konstantin	      chat with ==>ICQ: 109916175
     Lepikhov,	      speak  to ==>JID: lakostis@jabber.org
aka L.A. Kostis       write  to ==>mailto:lakostis@pisem.net.nospam

...The information is like the bank... 			  (c) EC8OR

Re: [sisyphus] КЮ. Часть 2

[Denis Smirnov]

On Sat, Apr 02, 2005 at 10:34:06AM +0600, Andrey Rahmatullin wrote:

AR> Не, чтоб конвертить всякие pciscan в конфиги ядра - это не знаю, какой ИИ
AR> нужен :( Из-за разнообразия как железа, так и конфигов...

Это нафиг не надо. А надо по крайней мере сборка под конкретный процессор,
автовыбор up/smp (с учётом гипертрединга это актуально, не все знают что
это уже smp), выбор настроек в зависимости от количества памяти.

А модулям место в initrd. Всем.

-- 
С уважением, Денис

http://freesource.info

[sisyphus] самонастраивающиеся ядра, хотпрыг на галушках и прочая ерунда (was: КЮ. Часть 2)

[Michael Shigorin]

On Sat, Apr 02, 2005 at 04:33:36PM +0400, Denis Smirnov wrote:
> AR> Не, чтоб конвертить всякие pciscan в конфиги ядра - это не знаю, какой ИИ
> AR> нужен :( Из-за разнообразия как железа, так и конфигов...
> Это нафиг не надо. А надо по крайней мере сборка под конкретный
> процессор, автовыбор up/smp (с учётом гипертрединга это
> актуально, не все знают что это уже smp), выбор настроек в
> зависимости от количества памяти.

Ты часом не путаешь с инсталером, а?

По части собсно ядра у меня сейчас пожеланий на полочке ровно два
-- одно, это чтоб бигмемские SMP не причисляли к i586, раз на ём
всё равно уже не работают, и уж совсем на полочке второе -- чтоб
rpm target приводил к автовыбору конфига.

_Кажется_, нечто подобное в старой схеме фигурировало, ну и
набор config-* там был немал.  Ну и если уж найдутся желающие
отслеживать-поддерживать, то чтоб конфиги на athlon не включали
всякого там i8xx audio/video/rng и прочего, что всё равно
неприменимо.

Но тратить на такой педантизм своё время не собираюсь, предлагать
потратить тому же vsu@ -- тем более.

Поэтому логичным будет предложить желающему сделать самому и
забросить результаты (если они воспоследуют) в devel-kernel@, 
а мы посмотрим, как оно ничего.  If.

> А модулям место в initrd. Всем.

/me представил себе сорокаметровый initrd и вздрогнул...

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

[sisyphus] Re: [JT] ядро самонастраивающееся, с неонкой унутре

[Michael Shigorin]

On Sat, Apr 02, 2005 at 02:00:34PM +0500, Boldin Pavel wrote:
> >Если есть такое непреоборимое желание раскладывать перед своей
> >системой грабли на ближайший апгрейд или сдыхание мамки -- вперёд
> >и с песнями, дорогой Леонардо. :)
> А никто не запрещает делать это _только_ после всех апгрейдов,
> к примеру когда есть сервер и его апгрейдеть ближайшие 1-2 года не 
> предвидится, можно собрать спец ядро и загрузиться из под него...
> когда прийдет пора апгрейда - просто загрузить стандартное ядро...

Круто.  У меня оборудование ещё не настолько дисциплинировано,
чтобы всенепременно доложить о намерении отдохнуть.

> чего в этом плохого? я же не предлагаю "заменить все ядра на
> оптимизированные"!

А вот это как раз зря -- какое-либо (возможно, опять же wks26?)
вполне может иметь смысл собирать как минимум под athlon, а если
допинать #5556 и #5274 -- то скорее athlonxp и pentium4.

> просто дать возможность сисадмину не копать спецификацию на
> машину и оборудование - просто взять и собрать новое ядро! :)

Сделайте и дайте другим возможность пользоваться этаким
автоблагом.  Видите ли, все мы хотим чего-то хорошего, но
реализация практически чего угодно требует некоторых знаний,
умений и времени.  Которые практически никогда не в избытке.

Поэтому кому больше всех горит -- тот и делает или заказывает.
Ну или провоцирует, но тогда _крайне_ желательно отчётливо
представлять себе как затраты на реализацию, так и пользу от
наличия, а также место получения этой самой пользы.  Плюс иметь
возможность так или иначе отблагодарить тех, кто делает.

Серьёзно -- если есть здоровье, интерес и время, подписывайтесь
на devel-kernel@ и пилите.  Правда, для разминки лучше составить
список интересных (используемых) пакетов, пройтись в bugzilla по
их открытым багам и постараться помочь их порешать -- вот от
такого при наличии эффекта и опыт, и почёт в одном флаконе.

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

Re: [sisyphus] самонастраивающиеся ядра, хотпрыг на галушках и прочая ерунда (was: КЮ. Часть 2)

[Denis Smirnov]

On Sat, Apr 02, 2005 at 08:32:33PM +0300, Michael Shigorin wrote:

AR>>> Не, чтоб конвертить всякие pciscan в конфиги ядра - это не знаю, какой ИИ
AR>>> нужен :( Из-за разнообразия как железа, так и конфигов...
>> Это нафиг не надо. А надо по крайней мере сборка под конкретный
>> процессор, автовыбор up/smp (с учётом гипертрединга это
>> актуально, не все знают что это уже smp), выбор настроек в
>> зависимости от количества памяти.
MS> Ты часом не путаешь с инсталером, а?

Дык подобные "автопересборки", в которых чуть ли не результат pciscan
собираются использовать -- это явно часть действий после инсталляции.

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

MS> По части собсно ядра у меня сейчас пожеланий на полочке ровно два
MS> -- одно, это чтоб бигмемские SMP не причисляли к i586, раз на ём
MS> всё равно уже не работают, и уж совсем на полочке второе -- чтоб
MS> rpm target приводил к автовыбору конфига.

Для меня нужно чтобы athlon/pentium4 ядра были собраны march+mcpu
athlon/pentium4.

MS> _Кажется_, нечто подобное в старой схеме фигурировало, ну и
MS> набор config-* там был немал.  Ну и если уж найдутся желающие
MS> отслеживать-поддерживать, то чтоб конфиги на athlon не включали
MS> всякого там i8xx audio/video/rng и прочего, что всё равно
MS> неприменимо.

Это уже дополнительная, приятная рюшечка, но уже скорее cleanup. А вот
сборка для конкретного процессора -- это выжимание производительности,
чего многие хотят.

MS> Но тратить на такой педантизм своё время не собираюсь, предлагать
MS> потратить тому же vsu@ -- тем более.
MS> Поэтому логичным будет предложить желающему сделать самому и
MS> забросить результаты (если они воспоследуют) в devel-kernel@, 
MS> а мы посмотрим, как оно ничего.  If.

Разумеется.

>> А модулям место в initrd. Всем.
MS> /me представил себе сорокаметровый initrd и вздрогнул...

Э... Я имел в виду что чем меньше будет в ядре, тем лучше. 

-- 
С уважением, Денис

http://freesource.info

[sisyphus] Re: самонастраивающиеся ядра, хотпрыг на галушках и прочая ерунда

[Michael Shigorin]

On Sat, Apr 02, 2005 at 11:48:43PM +0500, Boldin Pavel wrote:
> >Поэтому логичным будет предложить желающему сделать самому и
> >забросить результаты (если они воспоследуют) в devel-kernel@, 
> >а мы посмотрим, как оно ничего.  If.
> я попробую в свободное время этим занятся, хотябы с выбором
> архитектур,

Вот это правильно, это может и польза получиться.

> а апосля можно и подумать над hotplug и его конфигами и их 
> преобразовании в config ядра....

(а вот сюда пока доберётесь, наверняка более нужные вещи найдёте,
к которым получается напильник приложить :)

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

[sisyphus] Re: самонастраивающиеся ядра, хотпрыг на галушках и прочая ерунда (was: КЮ. Часть 2)

[Michael Shigorin]

On Sun, Apr 03, 2005 at 02:21:01PM +0400, Denis Smirnov wrote:
> >> Это нафиг не надо. А надо по крайней мере сборка под конкретный
> >> процессор, автовыбор up/smp (с учётом гипертрединга это
> >> актуально, не все знают что это уже smp), выбор настроек в
> >> зависимости от количества памяти.
> MS> Ты часом не путаешь с инсталером, а?
> Дык подобные "автопересборки", в которых чуть ли не результат
> pciscan собираются использовать -- это явно часть действий
> после инсталляции.

Ну, подразумевалось наличие оптимизированных ядер и, возможно,
glibc/zlib/gzip/bzip2/ещё_совсем_чуточки. :)

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

Вот я когда-то и предлагал более чётко "располосовать" ядерные
флаворы по части expected use и соответственно их балансировать.
Можно попробовать возобновить эту тему, если хотя бы Костик
прислушается. :)

> MS> По части собсно ядра у меня сейчас пожеланий на полочке ровно два
> MS> -- одно, это чтоб бигмемские SMP не причисляли к i586, раз на ём
> MS> всё равно уже не работают, и уж совсем на полочке второе -- чтоб
> MS> rpm target приводил к автовыбору конфига.
> Для меня нужно чтобы athlon/pentium4 ядра были собраны
> march+mcpu athlon/pentium4.

Ессно.  Ну и CONFIG_M* соответствующим.  Это ж как минимум.

> MS> _Кажется_, нечто подобное в старой схеме фигурировало, ну и
> MS> набор config-* там был немал.  Ну и если уж найдутся желающие
> MS> отслеживать-поддерживать, то чтоб конфиги на athlon не включали
> MS> всякого там i8xx audio/video/rng и прочего, что всё равно
> MS> неприменимо.
> Это уже дополнительная, приятная рюшечка, но уже скорее
> cleanup. А вот сборка для конкретного процессора -- это
> выжимание производительности, чего многие хотят.

О чём и спич.

> >> А модулям место в initrd. Всем.
> MS> /me представил себе сорокаметровый initrd и вздрогнул...
> Э... Я имел в виду что чем меньше будет в ядре, тем лучше. 

А, ну эт да.  Так апстрим тоже так думает, как ни странно. :)

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

Re: [sisyphus] КЮ. Часть 2

[Led]

В сообщении от Суббота 02 Апрель 2005 01:04 Boldin Pavel написал(a):
> Anton Gorlov aka stalker пишет:
> >Здравствуйте, ALT.
> >
> >На opennet сегодня прочитал:
> >
> >----------------
> >После того как Kenneth Chen, сообщил о результатах тестирования
> >Linux ядер 2.6.x, которые вскрыли неоднородность производительности
> >различных версий ядер серии 2.6 (например 2.6.11 оказалось на 13%
> >медленнее ядра используемого в RedHat Enterprise 3, 2.6.9 на 6%, а 2.6.8
> > на 23%), Linus Torvalds принял решение производить автоматизированное
> > ежедневное тестирование производительности всех выпускаемых
> > предварительных версий ядер.
> >-----------------
> >
> >
> >Оно действительно тормоз?
>
> Да нет, :) если пересобрать под свою машину - очень даже ничего...
>
> кстати, ALT, вам _действительно_ нехватает макросов к RPM которые бы
> собирали ядро с оптимизацией под машину (драйвера built-in и т.д.) на
> лету (без участия пользователя)
>
> набрал
> rpmbuild --rebuild kernel-image-opt26....
>
> и оно само определило железо и все остальное... вот так :)

Не надо такого. Потому как на одной машине не под одну субархитектуру ядра 
собираются, на серверах вобще компилятора нет. Достаточно адекватной рекции 
на --target, ну может ещё какие-нибудь "enable/disable" для rpm и hasher.

Led.

Re: [sisyphus] Re: самонастраивающиеся ядра, хотпрыг на галушках и прочая ерунда (was: КЮ. Часть 2)

[Denis Smirnov]

On Sun, Apr 03, 2005 at 09:36:59PM +0300, Michael Shigorin wrote:

> MS>> Ты часом не путаешь с инсталером, а?
>> Дык подобные "автопересборки", в которых чуть ли не результат
>> pciscan собираются использовать -- это явно часть действий
>> после инсталляции.
MS> Ну, подразумевалось наличие оптимизированных ядер и, возможно,
MS> glibc/zlib/gzip/bzip2/ещё_совсем_чуточки. :)

Из этого списка всё, кроме glibc, у меня уже прекрасно пересобирается под
athlon и выложено :)

>> А в зависимости от количества памяти, у нас же нет столько
>> ядер, чтобы это учесть.
MS> Вот я когда-то и предлагал более чётко "располосовать" ядерные
MS> флаворы по части expected use и соответственно их балансировать.
MS> Можно попробовать возобновить эту тему, если хотя бы Костик
MS> прислушается. :)

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

> MS>> По части собсно ядра у меня сейчас пожеланий на полочке ровно два
> MS>> -- одно, это чтоб бигмемские SMP не причисляли к i586, раз на ём
> MS>> всё равно уже не работают, и уж совсем на полочке второе -- чтоб
> MS>> rpm target приводил к автовыбору конфига.
>> Для меня нужно чтобы athlon/pentium4 ядра были собраны
>> march+mcpu athlon/pentium4.
MS> Ессно.  Ну и CONFIG_M* соответствующим.  Это ж как минимум.

Да. Собственно о чём я (чего я вообще влез), пока будет ставить задачу
максимум не решим ничего. А вот решить с "правильной" сборкой ядра
просто для i586/i686/athlon/pentium4 было бы весьма приятно и многих
жаждущих оптимизации успокоило бы надолго.

/me себе примерно представляет как это сделать (несколько скриптов на
sed).

Вопрос в следующем -- я себе это представляю как отдельную сущность
(пакет), в котором лежит набор sh+sed (а может и awk, ещё не знаю)
скриптов, которые "исправят" конфиг для конкретной архитектуры. Этот пакет
будет требоваться всеми ядрами, и соответствующий архитектуре скрипт из
него будет вызываться перез make oldconfig.

-- 
С уважением, Денис

http://freesource.info