Re: [devel] gcc 3.2... Мда... масса странностей.

Re: [devel] gcc 3.2... Мда... масса странностей.

[Dmitry V. Levin]

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

On Thu, Oct 31, 2002 at 12:52:29AM +0000, Igor Tertishny wrote:
> Я долго не решался написать это сообщение. Все проверял и проверял. На многих 
> компах, отнюдь не на одном. Теперь хочу вынести свое мнение на всеобщее 
> обсуждение.
> 
> Похоже, мы поторопились с переходом на gcc-3.2. Особенно это относится к 
> ядрам. Объясняю, почему я так думаю : я админ небольшой сети, всего десять 
> компов. Все работают на ALT Linux, потому могу сравнивать. После обновления 
> до новых ядер и прог, скомпиленных на компиляторе 3.2 на всех, я повторяю - 
> на всех компах сети, начались очень неприятные вещи. А именно: резкое 
> замедление работы, вплоть до полного зависания. Причем. сразу после загрузки 
> все в порядке, но потом начинается замедление, прогрессирующее со временем. 
> Если же загрузить ядро, скомпиленное на компиляторе 2.96, то этого не 
> происходит, система работает без замедления сколько угодно времени. От Х это 
> не зависит - то же самое происходит на двух серверах, на которых Х нет в 
> принципе. Даже, если ядро скомпилировано на этом самом компе - та же история. 
> Работать стало невозможно. Одна и та же файловая операция на ядре с 3.2 
> занимает примерно в 6!!! раз больше времени, чем на ядре с 2.96. Мне кажется, 
> что там где-то сильно не в порядке работа с IDE. Ничем иным я происходящее 
> объянить не могу.
> 
> Возможно, вы мне подскажете другие принципы мониторинга, чтобы окончательно 
> выяснить в чем тут дело. Но что-то нужно делать. Я понимаю, что глупо почти 
> все компы сети обновлять до Сизифа, но основные сервера как были Castle, так 
> ими и остались - не обновлял  и правильно сделал, как вижу. А рабочие компы - 
> почему бы и нет, тем более. что мне просто интересно проверять ALT на самом 
> разном железе.

Вы смешиваете разные вещи, а именно, kernel и userspace.

На серверах, предназначенных не для тестирования, а для выполнения
реальных задач, грамотные администраторы, как правило, собирают
custom-ядра.

Что касается приложений, то не вижу смысла задерживаться на 2.96.


--
ldv

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

[devel] gcc 3.2... Мда... масса странностей.

[Igor Tertishny]

Я долго не решался написать это сообщение. Все проверял и проверял. На многих 
компах, отнюдь не на одном. Теперь хочу вынести свое мнение на всеобщее 
обсуждение.

Похоже, мы поторопились с переходом на gcc-3.2. Особенно это относится к 
ядрам. Объясняю, почему я так думаю : я админ небольшой сети, всего десять 
компов. Все работают на ALT Linux, потому могу сравнивать. После обновления 
до новых ядер и прог, скомпиленных на компиляторе 3.2 на всех, я повторяю - 
на всех компах сети, начались очень неприятные вещи. А именно: резкое 
замедление работы, вплоть до полного зависания. Причем. сразу после загрузки 
все в порядке, но потом начинается замедление, прогрессирующее со временем. 
Если же загрузить ядро, скомпиленное на компиляторе 2.96, то этого не 
происходит, система работает без замедления сколько угодно времени. От Х это 
не зависит - то же самое происходит на двух серверах, на которых Х нет в 
принципе. Даже, если ядро скомпилировано на этом самом компе - та же история. 
Работать стало невозможно. Одна и та же файловая операция на ядре с 3.2 
занимает примерно в 6!!! раз больше времени, чем на ядре с 2.96. Мне кажется, 
что там где-то сильно не в порядке работа с IDE. Ничем иным я происходящее 
объянить не могу.

Возможно, вы мне подскажете другие принципы мониторинга, чтобы окончательно 
выяснить в чем тут дело. Но что-то нужно делать. Я понимаю, что глупо почти 
все компы сети обновлять до Сизифа, но основные сервера как были Castle, так 
ими и остались - не обновлял  и правильно сделал, как вижу. А рабочие компы - 
почему бы и нет, тем более. что мне просто интересно проверять ALT на самом 
разном железе.

Проше ваших мнений и помощи, сограждане по пингвину.

Re: [devel] gcc 3.2... Мда... масса странностей.

[Igor Tertishny]

> Вы смешиваете разные вещи, а именно, kernel и userspace.

Хорошо, пусть так. Но берем только рабочие компы с 3.2. Все, что я описал 
происходит с ними в действительности. И что мне с этим делать? Ведь 
замедление работы с течением времени идет. Я уже столько раз проверил, что... 
Как с этим бороться?

>
> На серверах, предназначенных не для тестирования, а для выполнения
> реальных задач, грамотные администраторы, как правило, собирают
> custom-ядра.
>

Сервера себе работают. Ядра именно те, о которых вы говорили. Не о них речь. 
Но если я пробовал пересобрать ядра для серверов с  gcc-3.2, то получал ту же 
историю. И возвращался к старым. Я не встречал еще ни одного работоспособного 
ядра, скомпиленного на 3.2. С этим-то как бороться?

Re: [devel] gcc 3.2... Мда... масса странностей.

[Anton Farygin]

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

Igor Tertishny пишет:

>>Вы смешиваете разные вещи, а именно, kernel и userspace.
>>    
>>
>
>Хорошо, пусть так. Но берем только рабочие компы с 3.2. Все, что я описал 
>происходит с ними в действительности. И что мне с этим делать? Ведь 
>замедление работы с течением времени идет. Я уже столько раз проверил, что... 
>Как с этим бороться?
>
Сколько времени уходит на то, что бы заметить замедление работы?

>
>  
>
>>На серверах, предназначенных не для тестирования, а для выполнения
>>реальных задач, грамотные администраторы, как правило, собирают
>>custom-ядра.
>>
>>    
>>
>
>Сервера себе работают. Ядра именно те, о которых вы говорили. Не о них речь. 
>Но если я пробовал пересобрать ядра для серверов с  gcc-3.2, то получал ту же 
>историю. И возвращался к старым. Я не встречал еще ни одного работоспособного 
>ядра, скомпиленного на 3.2. С этим-то как бороться?
>
Странно - у нас на нескольких серверах и на всех рабочих станциях оно 
работает.

Если есть где-то проблема, то давайте ее найдем сейчас, а не после 
выхода дистрибутива.

Rgds,
Rider


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

Re: [devel] gcc 3.2... Мда... масса странностей.

[Vitaly Lugovsky]

On Thu, 31 Oct 2002, Igor Tertishny wrote:

> > Вы смешиваете разные вещи, а именно, kernel и userspace.
> 
> Хорошо, пусть так. Но берем только рабочие компы с 3.2. Все, что я описал 
> происходит с ними в действительности. И что мне с этим делать? Ведь 
> замедление работы с течением времени идет. Я уже столько раз проверил, что... 
> Как с этим бороться?

 Если честно, то я вот до сих пор собираю все ядра с egcs. Иногда, в 
порядке экстрима (дабы адреналинчиком накачаться) - 2.95.3. И такая
вот политика всегда себя оправдывала.

> > На серверах, предназначенных не для тестирования, а для выполнения
> > реальных задач, грамотные администраторы, как правило, собирают
> > custom-ядра.
> >
> 
> Сервера себе работают. Ядра именно те, о которых вы говорили. Не о них речь. 
> Но если я пробовал пересобрать ядра для серверов с  gcc-3.2, то получал ту же 
> историю. И возвращался к старым. Я не встречал еще ни одного работоспособного 
> ядра, скомпиленного на 3.2. С этим-то как бороться?

 Выкручиванием рук ядреных хакеров, что, очевидно, невозможно. Они шибко 
заложились на особенности одного конкретного компилятора, о чём сам Линус
честно заявлял неоднократно...

Re: [devel] gcc 3.2... Мда... масса странностей.

[Vitaly Lugovsky]

On Thu, 31 Oct 2002, Anton Farygin wrote:

> Если есть где-то проблема, то давайте ее найдем сейчас, а не после 
> выхода дистрибутива.

 А может, не рвать в спешке анал, а просто собирать ядро хотя бы с 2.95.3,
никак не объясняя причин - хватит и практики.

Re: [devel] gcc 3.2... Мда... масса странностей.

[Igor Tertishny]

>
> Сколько времени уходит на то, что бы заметить замедление работы?
>

От часа, до трех. Но то, что хардиск работает примерно в два-три раза 
медленнее, чем на ядре с 2.96, заметно сразу. О чем речь, если загрузив два 
рядом стоящих компа с одинаковыми системами - Сизиф, количество пакетов 
приблизительно равно, один 500 на ядре скомпилированном на 2.96, а второй 
1800 на ядре скомпилированном на 3.2 - сразу видно разницу, 500 грузит 
графику (КДЕ) быстрее! Смешно, но факт. Загрузив же 1800-й на старом ядре, 
получаю действительно скоростную систему.

> Странно - у нас на нескольких серверах и на всех рабочих станциях оно
> работает.

Я компилил на gcc-3.2.1 зи Сизифа custom ядро прямо на сервере, сервер на 
Intel 450, 650 MB памяти. После загрузки этого ядра история в точности 
повторилась. Кстати, на этом же сервере заметил утечку памяти, уже через 
10-12 часов работы свободными остаются не более 1-2 процентов. ps не 
показывает ни единого зомби. На старом ядре этого тоже не происходит.

> Если есть где-то проблема, то давайте ее найдем сейчас, а не после
> выхода дистрибутива.

Ведь ради этого я и поднял проблему, чтобы разобраться в чем тут дело. Ну не 
может быть отсутствия ошибок, если на восьми совершенно разных по железу 
компах эффект повторяется с завидной регулярностью. Только комп с IDE Promise 
не дает замедления работы харда.

Re: [devel] gcc 3.2... Мда... масса странностей.

[Anton Farygin]

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

Vitaly Lugovsky пишет:

>On Thu, 31 Oct 2002, Anton Farygin wrote:
>
>  
>
>>Если есть где-то проблема, то давайте ее найдем сейчас, а не после 
>>выхода дистрибутива.
>>    
>>
>
> А может, не рвать в спешке анал, а просто собирать ядро хотя бы с 2.95.3,
>никак не объясняя причин - хватит и практики.
>  
>
Да никто не возражает.  Но эту позицию стоит обосновать ;-)

Т.е. - почему именно 2.95.3,  а не системный 3.2

В данный момент я не видел ни одного явного факта, который говорил бы, 
что ядро собранное gcc 3.2 работает хуже, чем ядро, собранное gcc 2.95.3.

Лучше всего конечно тест, явно показывающий эту разницу.

Rgds,
Rider


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

Re: [devel] gcc 3.2... Мда... масса странностей.

[Alexander Bokovoy]

On Thu, Oct 31, 2002 at 08:57:53PM +0300, Anton Farygin wrote:
> Vitaly Lugovsky пишет:
> 
> >On Thu, 31 Oct 2002, Anton Farygin wrote:
> >
> > 
> >
> >>Если есть где-то проблема, то давайте ее найдем сейчас, а не после 
> >>выхода дистрибутива.
> >>   
> >>
> >
> >А может, не рвать в спешке анал, а просто собирать ядро хотя бы с 2.95.3,
> >никак не объясняя причин - хватит и практики.
> > 
> >
> Да никто не возражает.  Но эту позицию стоит обосновать ;-)
> 
> Т.е. - почему именно 2.95.3,  а не системный 3.2
> 
> В данный момент я не видел ни одного явного факта, который говорил бы, 
> что ядро собранное gcc 3.2 работает хуже, чем ядро, собранное gcc 2.95.3.
> 
> Лучше всего конечно тест, явно показывающий эту разницу.
Тест очень прост: берем mutt и открываем им архив community@, который у
меня составляет за период с 15 мая этого года порядка 100Мб. При
закруженном Galeon с парой открытых страниц не самой большой сложности
(вроде www.mts.by, forum.onliner.by, www.uefa.com, навскидку), XChat с
полным протоколированием каналов (4 канала открыты, активности на них нет),
парой терминалов, Emacs, mpg123 и alicq. В процессе открытия архива нельзя не то
что работать, а зачастую и просто переключаться в WM с одного workplace на
другое.

Аналогичное на ядре 2.4.17/gcc 2.96 было значительно реактивнее.

-- 
/ Alexander Bokovoy
---
rain falls where clouds come
sun shines where clouds go
clouds just come and go
		-- Florian Gutzwiller

Re: [devel] gcc 3.2... Мда... масса странностей.

[Andrey Orlov]

On 2002 October 31 Thursday 20:57, you wrote:

Дайте я тоже подолью масла в огонь под gcc3.2.1 : Zope собранный gcc 3.2.1 уходит в бесконечный
рестарт. Лечится одним из двух способов : перекопиляцией библиотеки ExtensionClass.so без ключика -fPIC
или пересборкой с python2.1.3. Я выбрал первый способ как более, хм, ну короче мне так больше нравится и
я убил уже изрядно времени за последний год чбы Zope работал с питон 2.2., что бы поворачивать
назад из-за компилятора. В общем, к делу это не относится, я как видите проблему решил - хотя подозреваю не
самым интеллектуальным способом. Мбть кому-то это знание еще поможет. 

-- 
WthBstRgrds -- Андрей Орлов --  
 --- www.neural.ru, cray@neural.ru ---
----------------------------------------

Re: [devel] gcc 3.2... Мда... масса странностей.

[Vitaly Lugovsky]

On Thu, 31 Oct 2002, Anton Farygin wrote:

> >>Если есть где-то проблема, то давайте ее найдем сейчас, а не после 
> >>выхода дистрибутива.
> >
> > А может, не рвать в спешке анал, а просто собирать ядро хотя бы с 2.95.3,
> >никак не объясняя причин - хватит и практики.
> >  
> >
> Да никто не возражает.  Но эту позицию стоит обосновать ;-)

 Разве бОльшая пользовательская (тестовая) база варианта с egcs или 2.95,
плюс жалобы пользователей на решение с 3.2 - не достаточное обоснование?

> Т.е. - почему именно 2.95.3,  а не системный 3.2

 Лучше обкатано. Нет претензий к работе. И всё такое, в натуре...

> В данный момент я не видел ни одного явного факта, который говорил бы, 
> что ядро собранное gcc 3.2 работает хуже, чем ядро, собранное gcc 2.95.3.
> 
> Лучше всего конечно тест, явно показывающий эту разницу.

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

Re: [devel] gcc 3.2... Мда... масса странностей.

[Vitaly Lugovsky]

On Thu, 31 Oct 2002, Alexander Bokovoy wrote:

> > Т.е. - почему именно 2.95.3,  а не системный 3.2
> > 
> > В данный момент я не видел ни одного явного факта, который говорил бы, 
> > что ядро собранное gcc 3.2 работает хуже, чем ядро, собранное gcc 2.95.3.
> > 
> > Лучше всего конечно тест, явно показывающий эту разницу.
> Тест очень прост: берем mutt и открываем им архив community@, который у
> меня составляет за период с 15 мая этого года порядка 100Мб.

 Если проблемы с IDE и fs - то есть более-менее приличная попугаемерка -
Bonnie++. Так что - если у кого есть возможность - прошу погонять этот 
тест на двух разных ядрах с одинаковой конфигурацией на одинаковом железе.

> парой терминалов, Emacs, mpg123 и alicq. В процессе открытия архива нельзя не то
> что работать, а зачастую и просто переключаться в WM с одного workplace на
> другое.

 А hdparm в обоих случаях одно и то же говорит про этот диск?

Re: [devel] gcc 3.2... Мда... масса странностей.

[Vitaly Lugovsky]

On Thu, 31 Oct 2002, Andrey Orlov wrote:

> On 2002 October 31 Thursday 20:57, you wrote:
> 
> Дайте я тоже подолью масла в огонь под gcc3.2.1 : Zope собранный gcc 3.2.1 уходит в бесконечный
> рестарт. Лечится одним из двух способов : перекопиляцией библиотеки ExtensionClass.so без ключика -fPIC
> или пересборкой с python2.1.3. Я выбрал первый способ как более, хм, ну короче мне так больше нравится и
> я убил уже изрядно времени за последний год чбы Zope работал с питон 2.2., что бы поворачивать
> назад из-за компилятора. В общем, к делу это не относится, я как видите проблему решил - хотя подозреваю не
> самым интеллектуальным способом. Мбть кому-то это знание еще поможет. 

 Есть подозрение, что тут виноват не компилятор, а сама библиотека. Весьма
характерный симптомчик...

Re: [devel] gcc 3.2... Мда... масса странностей.

[Andrey Orlov]

On 2002 October 31 Thursday 21:28, you wrote:
>  Есть подозрение, что тут виноват не компилятор, а сама библиотека. Весьма
> характерный симптомчик...

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

А можно поподробнее про характерность симптомчика?

-- 
WthBstRgrds -- Андрей Орлов --  
 --- www.neural.ru, cray@neural.ru ---
----------------------------------------

Re: [devel] gcc 3.2... Мда... масса странностей.

[Vitaly Lugovsky]

On Thu, 31 Oct 2002, Andrey Orlov wrote:

> >  Есть подозрение, что тут виноват не компилятор, а сама библиотека. Весьма
> > характерный симптомчик...
> 
> Даже спорить не буду - виновата библиотека. Тем более что аналогичный
> симптом по слухам наблюдается на солярке и тому подобных местах.
> Но со старым компилятором работала на ура. Так что легкая претензия
> к компилятору имеет место быть - хотя как я уже объяснял, это можно 
> вылечить по-разному, в целом имеет место комплекс причин.

 Наоборот - компилятор благодарить надо, что он выявил трудноуловимый 
глючок.

> А можно поподробнее про характерность симптомчика?

 Наблюдается на C-шных и C++-ных программах при смене компилятора или 
опций оптимизации/дебага, а так же, но реже, при смене библиотек. Почти 
однозначно указывает на
1) неинициализированные переменные/структуры
2) выход за пределы структур/строк/массивов связанный с 1)

 То, что проявилось при -fPIC - только подтверждает подозрение 1).

Re: [devel] gcc 3.2... Мда... масса странностей.

[at]

On Thu, Oct 31, 2002 at 02:18:52AM +0300, Dmitry V. Levin wrote:
> Вы смешиваете разные вещи, а именно, kernel и userspace.
> 
> На серверах, предназначенных не для тестирования, а для выполнения
> реальных задач, грамотные администраторы, как правило, собирают
> custom-ядра.

Ядро "из коробки" должно работать железно на любых реальных задачах.
Иначе нас не поймут...

[devel] Re: gcc 3.2... íÄÁ... ÍÁÓÓÁ ÓÔÒÁÎÎÏÓÔÅÊ.

[Andrey Khavryuchenko]

Anton,

"AF" == Anton Farygin wrote:

 AF> В данный момент я не видел ни одного явного факта, который говорил бы,
 AF> что ядро собранное gcc 3.2 работает хуже, чем ядро, собранное gcc
 AF> 2.95.3.

Stock ядро -- не знаю.  openMosix живёт _только_ под 2.9[56] ядрами.

-- 
Andrey V Khavryuchenko          http://www.kds.com.ua/
Software Solutions

[devel] Re: [devel] gcc 3.2... Мда... масса странностей.

[Aleksandr Blokhin]

On Thu, 31 Oct 2002 15:10:28 +0000
Igor Tertishny <ilar@altlinux.ru> wrote:

>>
>> Сколько времени уходит на то, что бы заметить замедление работы?
>>

IT> От часа, до трех. Но то, что хардиск работает примерно в два-три
IT> раза 
IT> медленнее, чем на ядре с 2.96, заметно сразу. О чем речь, если
IT> загрузив два 

Я у себя не заметил никакого замедления, но у меня другое наблюдение 
- ядрёный плагин для rp-pppoe перестал работать на 3.2.
Помнится на второй или третьей сборке, попавшей в Сизиф, заработало, но
до следующего обновления gcc и с тех пор больше не дышит.

--
Best regards
AB
--
				... In nomine Altli, et Ctrli, et Spititus Deli, Reset!

[devel] Re: gcc 3.2... Мда... масса странностей.

[Vitaly Ostanin]

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

On Thu, 31 Oct 2002 23:10:52 +0300
at@turbinal.org wrote:

> On Thu, Oct 31, 2002 at 02:18:52AM +0300, Dmitry V. Levin
> wrote:
> > Вы смешиваете разные вещи, а именно, kernel и userspace.
> > 
> > На серверах, предназначенных не для тестирования, а для
> > выполнения реальных задач, грамотные администраторы, как
> > правило, собирают custom-ядра.
> 
> Ядро "из коробки" должно работать железно на любых реальных
> задачах. Иначе нас не поймут...

Вот-вот.
[занудно] iptables, iptables, reject, reject...

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

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

Re: [devel] gcc 3.2... Мда... масса странностей.

[Andrey Orlov]

On 2002 October 31 Thursday 22:21, you wrote:
>  Наоборот - компилятор благодарить надо, что он выявил трудноуловимый
> глючок.

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

> 1) неинициализированные переменные/структуры
> 2) выход за пределы структур/строк/массивов связанный с 1)

>  То, что проявилось при -fPIC - только подтверждает подозрение 1).

Спасибо. Стало ясно что искать ;)

-- 
WthBstRgrds -- Андрей Орлов --  
 --- www.neural.ru, cray@neural.ru ---
----------------------------------------

Re: [devel] gcc 3.2... Мда... масса странностей.

[Vitaly Lugovsky]

On Fri, 1 Nov 2002, Andrey Orlov wrote:

> >  Наоборот - компилятор благодарить надо, что он выявил трудноуловимый
> > глючок.
> 
> Вот тут я не соглашусь - если чей-то автомобиль выявил трудноуловимый
> глючок, что меня  укачивает - то это еще не значит, что я должен его 
> благодарить.
> Впрочем это даже не вопрос разных взглядов, а вопрос их разного 
> наименования ;)

 Почему же? Аналогия неверная. Такого рода глюки всё равно будут 
проявляться, причём - когда их совсем не ждут. А если подфортило и 
компилятор вынес глюку на первый план - то появляется возможность её 
исправить. Если укачивает - то всё, ничего не поделать, а вот если 
попалась глюка - надо радоваться и давить её всячески.

> > 1) неинициализированные переменные/структуры
> > 2) выход за пределы структур/строк/массивов связанный с 1)
> 
> >  То, что проявилось при -fPIC - только подтверждает подозрение 1).
> 
> Спасибо. Стало ясно что искать ;)

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

Re: [devel] gcc 3.2... Мда... масса странностей.

[Victor Forsyuk]

On Thu, Oct 31, 2002 at 01:31:49AM +0000, Igor Tertishny wrote:
> >
> 
> Сервера себе работают. Ядра именно те, о которых вы говорили. Не о них
> речь.  Но если я пробовал пересобрать ядра для серверов с gcc-3.2, то
> получал ту же историю. И возвращался к старым. Я не встречал еще ни одного
> работоспособного ядра, скомпиленного на 3.2. С этим-то как бороться?

Бороться - никак. Смириться. И перейти на сборку ядер gcc 2.95 -
имею в виду не Вам лично, а ALT Linux.

Кстати, в свете предстоящей заморозки перед бета-тестированием
следующего релиза стоило бы пересобрать как можно раньше, чтобы
было больше времени на тестирование стабильности самого ядра, а
не на укрепление убежденности, что linux kernel и gcc > 2.95
несовместимы.

p.s. Just IMHO, но на секс имени сборки ядра не тем компилятором,
что стоит у ядреных хакеров я в прошлом насмотрелся... ;(

Re: [devel] gcc 3.2... Мда... масса странностей.

[Victor Forsyuk]

On Thu, Oct 31, 2002 at 08:57:53PM +0300, Anton Farygin wrote:
> >
> >А может, не рвать в спешке анал, а просто собирать ядро хотя бы с 2.95.3,
> >никак не объясняя причин - хватит и практики.
> > 
> >
> Да никто не возражает.  Но эту позицию стоит обосновать ;-)
> 
> Т.е. - почему именно 2.95.3,  а не системный 3.2

Потому что 2.95.* - последняя приличная версия gcc, которая
собирала более-менее рабочие ядра.
 
> В данный момент я не видел ни одного явного факта, который говорил бы, 
> что ядро собранное gcc 3.2 работает хуже, чем ядро, собранное gcc 2.95.3.
> 
> Лучше всего конечно тест, явно показывающий эту разницу.

Да, конечно лучше. Всегда лучше иметь четко документированные
доказательства, с цифрами, таблицами, с описанием воспроизводимых
ситуаций ("в такой конфигурации делаем N раз то-то и то-то, с
этим ядром всё хорошо, а с этим жопа").

Это можна даже в lkml показать. Только это ничего не изменит,
ядро линукса это не обычная программа и не стоит надеяться, что
ядреные хакеры будут прилагать усилия для того, чтобы оно
_корректно_ компилялось современными компиляторами.

[devel] Re: gcc 3.2... Мда... масса странностей.

[Mikhail Zabaluev]

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

Hello Victor,

On Fri, Nov 01, 2002 at 08:17:17PM +0200, Victor Forsyuk wrote:
>
> On Thu, Oct 31, 2002 at 08:57:53PM +0300, Anton Farygin wrote:
> > >
> > >А может, не рвать в спешке анал, а просто собирать ядро хотя бы с 2.95.3,
> > >никак не объясняя причин - хватит и практики.
> > > 
> > >
> > Да никто не возражает.  Но эту позицию стоит обосновать ;-)
> > 
> > Т.е. - почему именно 2.95.3,  а не системный 3.2
> 
> Потому что 2.95.* - последняя приличная версия gcc, которая
> собирала более-менее рабочие ядра.

Скажем так: последняя версия, притёртая
к некоторым привычкам kernel hacker'ов.

P.S. У меня пока с 3.2-шным ядром полёт нормальный. Никаких
крэшей и замедлений. Или это Pentium 4 2.26 GHz выручает? :)

-- 
Stay tuned,
  MhZ                                     JID: mookid@jabber.org
___________
A great nation is any mob of people which produces at least one honest
man a century.

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

Re: [devel] Re: gcc 3.2... Мда... масса странностей.

[Dmitry Lebkov]

On Sat, 2 Nov 2002 13:00:21 +0300
Mikhail Zabaluev <mhz@altlinux.org> wrote:

> Hello Victor,
> 
> On Fri, Nov 01, 2002 at 08:17:17PM +0200, Victor Forsyuk wrote:
> >
> > On Thu, Oct 31, 2002 at 08:57:53PM +0300, Anton Farygin wrote:
> > > >
> > > >А может, не рвать в спешке анал, а просто собирать ядро хотя бы с 2.95.3,
> > > >никак не объясняя причин - хватит и практики.
> > > > 
> > > >
> > > Да никто не возражает.  Но эту позицию стоит обосновать ;-)
> > > 
> > > Т.е. - почему именно 2.95.3,  а не системный 3.2
> > 
> > Потому что 2.95.* - последняя приличная версия gcc, которая
> > собирала более-менее рабочие ядра.
> 
> Скажем так: последняя версия, притёртая
> к некоторым привычкам kernel hacker'ов.
> 
> P.S. У меня пока с 3.2-шным ядром полёт нормальный. Никаких
> крэшей и замедлений. Или это Pentium 4 2.26 GHz выручает? :)

Скорее "нет", чем "да". На двух машинах (домашней и рабочей)
вполне нормально вертится уже около двух недель. Рабочая вообще
не выключается. Правда обе они SMP: 2xPII-350 и 2xPIII-500,
чипсет - BX.


WBR, Dmitry Lebkov

Re: [devel] gcc 3.2... Мда... масса странностей.

[Igor Tertishny]

Четверг 31 Октябрь 2002 19:57, Anton Farygin написал:
> Vitaly Lugovsky пишет:
> >On Thu, 31 Oct 2002, Anton Farygin wrote:
> >>Если есть где-то проблема, то давайте ее найдем сейчас, а не после
> >>выхода дистрибутива.
> >
> > А может, не рвать в спешке анал, а просто собирать ядро хотя бы с 2.95.3,
> >никак не объясняя причин - хватит и практики.
>
> Да никто не возражает.  Но эту позицию стоит обосновать ;-)
>
> Т.е. - почему именно 2.95.3,  а не системный 3.2
>

Обосновываю: 

Я скомпилил ядро для основного сервера на 3.2.1, 2.95.3 и icc (Intel 
Compiler). на 3.2.1 через 10-12 часов наблюдается забивка всей памяти (650 
Мег) под завязку и дикое замедление работы. Ядро на 2.95.3 работало неделю 
чудненько и ничего из вышеописанного не происходило. причем!!! Это Master, 
почти не обновленный. А вот интеллевский компилятор  - это просто песня. 
Жаль, что он сволочь, не GNU. Ох как жаль... Вся работа ускорилась в полтора 
раза! Никаких замедлений, никаких непонятных потерь памяти. Что с 3.2.1 
сильно не так и именно в работе с файловыми системами. Конкретно, с моей 
любимой ext3. 

Re: [devel] gcc 3.2... Мда... масса странностей.

[Vitaly Lugovsky]

On Fri, 8 Nov 2002, Igor Tertishny wrote:

> Я скомпилил ядро для основного сервера на 3.2.1, 2.95.3 и icc (Intel 
> Compiler). на 3.2.1 через 10-12 часов наблюдается забивка всей памяти (650 
> Мег) под завязку и дикое замедление работы. Ядро на 2.95.3 работало неделю 
> чудненько и ничего из вышеописанного не происходило. причем!!! Это Master, 
> почти не обновленный. А вот интеллевский компилятор  - это просто песня. 
> Жаль, что он сволочь, не GNU. Ох как жаль... Вся работа ускорилась в полтора 
> раза! Никаких замедлений, никаких непонятных потерь памяти. Что с 3.2.1 
> сильно не так и именно в работе с файловыми системами. Конкретно, с моей 
> любимой ext3. 

 Ой. А можно патчик на makefile показать, который дабы icc пользовать для?

Re: [devel] gcc 3.2... Мда... масса странностей.

[Igor Tertishny]

>
>  Ой. А можно патчик на makefile показать, который дабы icc пользовать для?
>
>
Дык я без оного, подключил еще один пункт в update-alternatives на c++, gcc, 
g++ и вперед, установив его компальером по умолчанию. Помню эксперементировал 
немало, прежде чем получилось.

Re: [devel] gcc 3.2... Мда... масса странностей.

[Alexey Morozov]

On Sat, Nov 09, 2002 at 11:16:05PM +0200, Igor Tertishny wrote:
> Дык я без оного, подключил еще один пункт в update-alternatives на c++, gcc, 
> g++ и вперед, установив его компальером по умолчанию. Помню эксперементировал 
                                                              ^^^^^^^^^^^^^^^^^
> немало, прежде чем получилось.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Рецепт - в студию :-)

Re: [devel] gcc 3.2... Мда... масса странностей.

[Vitaly Lugovsky]

On Sat, 9 Nov 2002, Igor Tertishny wrote:

> >  Ой. А можно патчик на makefile показать, который дабы icc пользовать для?
> >
> >
> Дык я без оного, подключил еще один пункт в update-alternatives на c++, gcc, 
> g++ и вперед, установив его компальером по умолчанию. Помню эксперементировал 
> немало, прежде чем получилось.

 Так там же ещё кучу файлов патчить надо, где неподдерживаемые гнутые 
расширения используются. Мне влом это делать, так что, может быть, в эху 
патчик?

Re: [devel] gcc 3.2... Мда... масса странностей.

[Igor Tertishny]

>
>  Так там же ещё кучу файлов патчить надо, где неподдерживаемые гнутые
> расширения используются. Мне влом это делать, так что, может быть, в эху
> патчик?
>

Смотрите, люди, я патч не делал. Компилил наобум, ручками. даже не все помню 
сейчас - сидел на работе, смена была 18 часов, скучно было и я занялся. 
Помню, что сил и времени приложил до фига и больше, но многие детали - 
подзабыл. Главное было все переменные в консоли переопределить. С ними тоже 
возни было. Давайте, я попробую написать спеку под icc. Или вседу все таки в 
патчик и опробую на паре-тройке компов. Мне ребята инфу по сему поводу 
обещались завтра-послезавтра подкинуть. Но быстро не получится, ближайшее 
время сильно занят. В успехе тоже не уверен, у меня с этим ядром иногда 
возникает чувство, что все получилось чисто случайно - ни на одном другом 
компе пока не скомпилилось. Только этот леп. Да и на нем повторно не 
пробовал, скомпиленное ядро просто тупо перепер на сервер и оно, на 
удивление, поднялось. 

[devel] Re: gcc 3.2... Мда... масса странностей.

[Michael Shigorin]

On Sun, Nov 10, 2002 at 05:09:31PM +0300, Vitaly Lugovsky wrote:
> Так там же ещё кучу файлов патчить надо, где неподдерживаемые
> гнутые расширения используются. 

Если я правильно помню, на страничке icc была информация именно
насчет ядер -- вроде дописали они эти расширения?  Правда, руки
никак не дойдут проверить ;-(

А nosrc.rpm, наверное, не помешал бы.

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

Re: [devel] Re: gcc 3.2... Мда... масса странностей.

[Igor Tertishny]

>
> А nosrc.rpm, наверное, не помешал бы.

Вот им я и попробую заняться.

Re: [devel] Re: gcc 3.2... Мда... масса странностей.

[Vitaly Lugovsky]

On Mon, 11 Nov 2002, Michael Shigorin wrote:

> On Sun, Nov 10, 2002 at 05:09:31PM +0300, Vitaly Lugovsky wrote:
> > Так там же ещё кучу файлов патчить надо, где неподдерживаемые
> > гнутые расширения используются. 
> 
> Если я правильно помню, на страничке icc была информация именно
> насчет ядер -- вроде дописали они эти расширения?  Правда, руки
> никак не дойдут проверить ;-(
> 
> А nosrc.rpm, наверное, не помешал бы.

 Ну дык они так и написали, что ручками устраняли по всем сырцам
неподдерживаемые гнутые расширения... Я попробовал - мало не показалось,
на где-то 20м файле сломался.

Re: [devel] Re: gcc 3.2... Мда... масса странностей.

[Igor Tertishny]

>
>  Ну дык они так и написали, что ручками устраняли по всем сырцам
> неподдерживаемые гнутые расширения... Я попробовал - мало не показалось,
> на где-то 20м файле сломался.
>

Во-во, этим-то я со скуки и маялся. Но можно попробовать сообразить фильтры с 
помощью sed и awk. буду пробовать, авось что и получится.

Re: [devel] Re: gcc 3.2... Мда... масса странностей.

[Vitaly Lugovsky]

On Mon, 11 Nov 2002, Igor Tertishny wrote:

> >  Ну дык они так и написали, что ручками устраняли по всем сырцам
> > неподдерживаемые гнутые расширения... Я попробовал - мало не показалось,
> > на где-то 20м файле сломался.
> >
> 
> Во-во, этим-то я со скуки и маялся. Но можно попробовать сообразить фильтры с 
> помощью sed и awk. буду пробовать, авось что и получится.

 Разгребать структурированную, сложную грамматику sed-ом? Ужас.
У меня тут более другая мысль: прогнать всё через вумный препроцессор,
построенный на основе того же CIL-а:

 http://manju.cs.berkeley.edu/cil/

 Насколько я в прошлый раз посмотрел, CIL знает все гнутые расширения...
А если и не знает - научить можно, AST вполне расширябелен.

Кстати, за компанию можно и фильтры на всякие грубые ошибки с памятью
и с security понавешать, для того CIL и создавался...

 Кстати, зря в нынешней системе сборки ядра не предусмотрен обязательный
внешний препроцессор. Для столь крупногабаритных монолитных программных 
продуктов это вообще-то must have.

Re: [devel] Re: gcc 3.2... Мда... масса странностей.

[Igor Tertishny]

>
>  Разгребать структурированную, сложную грамматику sed-ом? Ужас.
> У меня тут более другая мысль: прогнать всё через вумный препроцессор,
> построенный на основе того же CIL-а:
>
>  http://manju.cs.berkeley.edu/cil/
>
>  Насколько я в прошлый раз посмотрел, CIL знает все гнутые расширения...
> А если и не знает - научить можно, AST вполне расширябелен.

Надо посмотреть, что это там такое. Не слышал даже, откровенно говоря.

>
> Кстати, за компанию можно и фильтры на всякие грубые ошибки с памятью
> и с security понавешать, для того CIL и создавался...

Обязательно посмотрю, что это за штука. Но пока еще научищься ею 
пользоваться.. Кстати, у icc проблема ведь еще в том, что неизвестно, как он 
будет с атлоновскими процами работать.

>
>  Кстати, зря в нынешней системе сборки ядра не предусмотрен обязательный
> внешний препроцессор. Для столь крупногабаритных монолитных программных
> продуктов это вообще-то must have.

Полностью согласен. Я последнее время вплотную занимаюсь ядрами и, мамочки 
мои, что за кошмар. Куда ни двинь - грабли. То не так, се не работает, там - 
проблема. Особенно с нестандартным железом. Мы ведь планируем выпускать 
сервера на Альте. Простенькие - файловые и Веб. У нас, в Израиловке, сейчас 
резко подымается интерес к Линуху и на этом можно сыграть. Но для такого дела 
ядрышки должны быть отлизаны до полного блеска. Вот и маюсь... Делать что-то 
надо, сколько же можно в охране сидеть? Надоело-с. Хоть и леп под боком, и 
сеть подымать начальство не своего админа (коий полный дуб, изучавший три 
семестра в универе курс "Окна" - о том, как открывать и закрывать оные - и 
это правда, сам программу курса читал, загибаясь со смеху), а охранника зовет 
в случае чего. Но надоело. Хочу заниматься Линухом, Линухом и еще раз 
Линухом.

Re: [devel] Re: gcc 3.2... Мда... масса странностей.

[Vitaly Lugovsky]

On Tue, 12 Nov 2002, Igor Tertishny wrote:

> >  http://manju.cs.berkeley.edu/cil/
> >
> >  Насколько я в прошлый раз посмотрел, CIL знает все гнутые расширения...
> > А если и не знает - научить можно, AST вполне расширябелен.
> 
> Надо посмотреть, что это там такое. Не слышал даже, откровенно говоря.

 Это framework для построения всяких 
фильтров/препроцессоров/анализаторов/верификаторов/компиляторв для языка 
Си и подобных ему. Есть несколько готовых приложений для примеру: 
pretty-printer (вот его нам и надо помодифицировать, изменения должны быть 
минимальными), рисовалка графов зависимостей, и ещё какие-то мелочи. 
Драйвер евонный из себя gcc умеет изображать, дабы особо Makefile-ы не 
менять.

> > Кстати, за компанию можно и фильтры на всякие грубые ошибки с памятью
> > и с security понавешать, для того CIL и создавался...
> 
> Обязательно посмотрю, что это за штука. Но пока еще научищься ею 
> пользоваться.. Кстати, у icc проблема ведь еще в том, что неизвестно, как он 
> будет с атлоновскими процами работать.

 Известно. Плохо будет работать. Атлону придётся из себя ПеньПро 
изображать, с MMX, не выше.

> >  Кстати, зря в нынешней системе сборки ядра не предусмотрен обязательный
> > внешний препроцессор. Для столь крупногабаритных монолитных программных
> > продуктов это вообще-то must have.
> 
> Полностью согласен. Я последнее время вплотную занимаюсь ядрами и, мамочки 
> мои, что за кошмар. Куда ни двинь - грабли. То не так, се не работает, там - 
> проблема. Особенно с нестандартным железом. Мы ведь планируем выпускать 
> сервера на Альте. Простенькие - файловые и Веб.

 Для простеньких - не надо нестандартного железа. ;)

> У нас, в Израиловке, сейчас 
> резко подымается интерес к Линуху и на этом можно сыграть. Но для такого дела 
> ядрышки должны быть отлизаны до полного блеска.

 При нынешней методике разработки ядра, навязанной экстремалом 
Торвальдсом, такое вряд ли возможно. Правда, кто-то (SGI, кажется), не так
давно пропесочил ядро, воспользовавшись самописным верификатором, поверх
GCC сделанным, размеры их патчей (и ведь они только грубейшие ошибки и
race conditions ловили!) просто устрашали. Ну так вот, стоит с CIL
повозиться, для верификации это куда как более подходящая платформа, чем
GCC. У меня были кой-какие наработки на тему полнотекстного 
dataflow-анализа и суперкомпиляции, можно и на благо общества их 
применить. Вот только, было бы время свободное... :(

> Вот и маюсь... Делать что-то 
> надо, сколько же можно в охране сидеть? Надоело-с. Хоть и леп под боком, и 
> сеть подымать начальство не своего админа (коий полный дуб, изучавший три 
> семестра в универе курс "Окна" - о том, как открывать и закрывать оные - и 
> это правда, сам программу курса читал, загибаясь со смеху),

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

> а охранника зовет 
> в случае чего. Но надоело. Хочу заниматься Линухом, Линухом и еще раз 
> Линухом.

 Линух - это явление временное. Лучше заниматься программированием вообще. 
Или хотя бы системным программированием в частности. 

Re: [devel] Re: gcc 3.2... Мда... масса странностей.

[Igor Tertishny]

>
>  Это framework для построения всяких
> фильтров/препроцессоров/анализаторов/верификаторов/компиляторв для языка
> Си и подобных ему. Есть несколько готовых приложений для примеру:
> pretty-printer (вот его нам и надо помодифицировать, изменения должны быть
> минимальными), рисовалка графов зависимостей, и ещё какие-то мелочи.
> Драйвер евонный из себя gcc умеет изображать, дабы особо Makefile-ы не
> менять.

попробую освоить.

>  Известно. Плохо будет работать. Атлону придётся из себя ПеньПро
> изображать, с MMX, не выше.

Это-то и не здраво, атлонов сейчас много. У меня самого два. На Интеле только 
леп и комп соседа по квартире. На нем и придется экспериментировать.

>
> > >  Кстати, зря в нынешней системе сборки ядра не предусмотрен
> > > обязательный внешний препроцессор. Для столь крупногабаритных
> > > монолитных программных продуктов это вообще-то must have.

А что здесь можно сделать? 

Ладно, хоть для Интелей попробую. Ибо ядрышко, коее скомпилил чудом, работает 
отлично, очень многие процессы ускорились. О чем говорить, даже 
Интернет-коннект заработал процетов на тридцать быстрее. Вопрос, что с 
Атлоном делать? На нем пользуюсь ядрами, компиленными на 2.95.3 как для i686. 
Тоже многое ускорилось.