Re: [Comm] [d-kernel] собственно , USB и картина маслом (compact 3)

[Michael Shigorin <mike@osdn.org.ua>]

On Wed, Sep 27, 2006 at 09:40:05AM +0700, Gleb Kulikov wrote:
> Сложно. Много качать (проверять-то надо по возможности, полную
> систему, ага?), почти нереально.

Зачем полную?  Минимальную с необходимым для монтирования.

> Михаил, я не хотел никого обидеть, поймите правильно.

Да понимаю.

> Но как иначе, ведь это фундаментальные, даже не "глюки",
> просчёты. И в них надо разбираться, имхо.  Если виноват
> мэйнстрим, так значит, надо об этом орать на каждом углу.
> И тюкать разработчиков, пока не проникнутся :)

А они годами могут проникаться.  Мы тут с год тому делали
подставку под одну штуковину (мультитредовый специализированный
сервер), так там только после снижения HZ с 1000 до 100, как
в 2.4, удалось на 2.6.10 терять всего (!) 20% производительности
относительно RH7.3.  При рядом стоящих 2.6 и 2.4 загрузка в
старое ядро тоже не радовала -- оно просто взлетало относительно
2.6...

> Система по факту, превращается в неработоспособную, глюк с
> несрабатыванием семафоров и пропуском сигналов, меня убил.

Я бы сперва железо думал.  memtest, cpuburn, ...

> Надо же разбираться... когда 3 гигагерцовая машина не может
> обслужить 5 хилых клиентов --- я не знаю, как это назвать. Что
> это, дефекты локальной сборки, побочный эффект отсутствия до
> сих пор ?!!!

Ну мне вот не попадалось.

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

Ага, начиная с Cel433.

> и это не так заметно, или дефект исправлен на новых ядрах -- но
> мне-то это проверить, невозможно, поэтому и дёргаюсь!

Стоп.  На каких это вылазит/началось?

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

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

В частности, и поэтому сравнивать последние 2.4 (e.g. 2.4.26)
и первые 2.6 (~2.6.8) было совсем грустно.

> А на сизифе, имхо, реальное тестирование таких фундаментальных
> штучек, невозможно: глюки проявляются при длительной *реальной*
> работе.

С openvz и vserver получается иметь под сизифом и свежим ядром
стабильное окружение (или даже несколько).  У нас сейчас вон 
LTSP с ALC3.0 работает под Sisyphus/x86_64.

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

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

> Раз уж заявили окончательный переход на новое ядро, а оно вон
> как оказывается... скреплённым жвачкой и изолентой, и
> разваливающимся при самом слабом ветре.

Не, ну его уже довольно давно собирает стабильный майнтейнер. :)

Глеб, вообще если есть какое-то время/здоровье и странный
энтузиазм -- пойдёмте в команду.  Иногда действительно
получается, что небольшое приложение напильника позволяет
разгрузить тех, кого в результате можно попросить обратить
более пристальное внимание на более важные проблемы, чем
мелочёвка всякая.

Например, посмотрите в bugzilla на баги, которые сейчас висят на
nobody altlinux org -- есть ли среди них интересные и которые
вроде как посильно починить?

Ну и разумеется -- перед тем, как тратить на что-то заметное 
время, стоит посмотреть и взвесить свои варианты.  Я с год
назад этим озадачивался; результат, думаю, понятен.

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