тороза
В общем сидел я раньше на слаквари и ядре 2.4.x...
железо AthlonXP 1800(1500real), 512Mb...
Сижу под гномом...
После переезда на генту(последню, с минималцд, все с нета) порадовала скорость в некоторых местах(например отображение гтк-шных виджетов)... Но через некоторое время начали периодически заменты торомоза... Сначала думал своп - однако со времен слаквари ничего с объемами памяти не изменилось... У меня 6 рабочих столов почти всегда все забиты(firefox, bmp, thunderbird, gvim, gnome-terminal)... Иногда еще подвисает bmp, но это из-за плагина immsd - оно и на слаквари подвисало при огромных плэйлистах... проблема в другом... если на слаквари при подвисании все остальное фурычило нормально(хотя и камень загружен был по полной), то теперь при подвисании даже мышка "еле ездит", то есть с тормозами... убить bmp при этом - целаа проблема...
Аналогично при пожати homevideo(жму mpeg2enc)... В слаквари пожизненно жал во время работы - просто пускал сжималку по nice -n19 и спокойно работал, совершенно не замечая никаких тормозов... сейчас же - даже визуально бывает видна прорисовка окон при переключении между столами или окнами...
С чем это могет быть связано? Варианты, которые я смог предположить:
1) При оптимизации на athlon-xp и 3dnow все софтины стали жрать больше памяти... Но это вряд ли причина, так как при зависании bmp к примеру, винт ваще молчит, а вся система уходит в тормоза ужасные... то есть именно по камню...
2) Что то не так скомпилял(иксы или еще что)
3) Думаю наиболее вероятно: где то слышал что в ядре 2.6 другой шедулер или еще что то... типа заточено под десктоп круче... Может быть с этим как то связано? Что стоит посмотреть в настройках ядра?
Спасибо.
- Для комментирования войдите или зарегистрируйтесь
Попоробуйте
Попоробуйте собрать preemt ядро (указать соответствующий пункт в кофиге)
изначально с
изначально с этой фичей собрано... однако пробовал и убирать - никаких изменений :(
1. проверяем
1. проверяем звездочку на юдма при hdparm -i /dev/hdxy
2. пробуем собирать прежде всего glibc и ядро без оптимизаций
3. пробуем ядра lova-sources или nitro-sources там другие шедулеры
Re: 1. проверяем
1. Ну не первый день замужем :)
fly-ws ~ # hdparm /dev/hda
/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 16383/255/63, sectors = 40020664320, start = 0
2. Это как? Вернее какой в этом смысл и обоснование? Почему об этом нигде не говорят? В общем подробнее мона?
3. Как то хотелось бы на стандарте - у всех же вроде все ок... Или я просто такой придирчивый?
> 2. Это как?
> 2. Это как? Вернее какой в этом смысл и обоснование? Почему об этом нигде не говорят? В общем подробнее мона?
некоторые алгоримты при сборке с оптимизацией очевидно преобразуются в более медленный код, хотя у меня давно уже почемуто все работает как надо в плане скорости, может потому что я забыл про верчение флагами:)
А может
А может попробовать поиграться с приоритетами процессов?