Я много копировал по wifi (вплоть до нескольких часов на одно копирование), неоднократно писал на флешку (она не очень большая, там по несколько минут копировалось), копировал по локалке... лагов и подвисаний в GUI не наблюдал. ЧЯДНТ?

12309 и атом.
лечится покупкой нового компа.

Можно ли как-то с этим бороться? Хотя бы частично компенсировать чем-то этот эффект, чтобы во время дисковых операций компьютером можно было продолжать пользоваться.

установи венду!

Она на атомах ведёт себя так всё время (в магазине видел), а не только во время копирования ;)

>Насколько я понимаю, именно это вызывает жуткие подвисания во время дисковых операций (до секунды и более)

абсолютно не из за этого


1) поставить ядро 2.6.34 , там оптимизировали IO
2) поставить ядро с BFS патчем ( brain f*ck scheduler by Con Kolivas )
это -zen -ck или -bfs ядра
BFS более эффективно распределяет процессорное время и не дает IO-wait «захватить» процессор настолько что кажется что все тормозит

3)
for i in `pidof kjournald` ; do ionice -c1 -p $i ; done
echo 4096 > /sys/block/sda/queue/nr_requests


4) файловые системы монтируете с relatime опцией (или noatime как вариант)

>>Насколько я понимаю, именно это вызывает жуткие подвисания во время дисковых операций (до секунды и более)

абсолютно не из за этого

Почему я так решил - потому что рядом стоит старенький селерон 2Г, и таких проблем при копировании никогда не возникает.

1,2 - попробую, 4 - уже. А 3 - это для чего?

Описанные вами проблемы связаны явно с чем-то другим. Либо у вас какая-то неисправность железа, либо какое-то очень-очень неправильное ядро. Сообщите версии дистрибутива и ядра, а также точный тип нетбука.

celeron 2 Ghz быстрее атома , тормоза при копировании из за драйвера чипсета, и уж ни коим образом не связаны с моделью in-order execution

3)
это настройка увеличенной очереди запросов на диск sda
и задание наивысшего приоритета ionice для процесса журналирования

> Сообщите версии дистрибутива и ядра, а также точный тип нетбука.

Eee PC 901
Ubuntu 10.04, 2.6.32-22

Сейчас поставил 2.6.35-4, тестю. Пока много памяти свободной, поэтому тормоза слабо наблюдаются. Но есть. Чуть позже отпишу о результатах. Еще попробую таки собрать с BFS.

> тормоза при копировании из за драйвера чипсета, и уж ни коим образом не связаны с моделью in-order execution

Не спорю.

celeron 2 Ghz быстрее атома

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

Не забывайте о системной шине, о расширениях процессора и так далее.

Я вам заявляю не теоретически, а основываясь на практических наблюдениях. Две машины стоят рядом, на старой много работал раньше, на новой - сейчас. Так вот:
1. На старой стоит гном. Четвертые кеды там не тянутся никак. На EeePC кеды нормально работают.
2. Видео на ютубе на EeePC смотрится куда лучше, чем на старом.
3. Фильмы нетбук тянет те, что на старом - слайдшоу.
4. Множество одновременно запущенных приложений куда легче переносится, чем на старом компе. Даже eclipse без особого напряга тянет.
И так делее.

С ядром 2.6.35 не полегчало.

Потыкай разные live-usb (slax например) и посмотри как оно будет вести себя с ванильным и другими не бубунтячьими ядрами.

Можно попробовать скомпилировать ядро с помощью GCC 4.5, он имеет опцию -march=atom, а также ядро с 2.6.32 имеет опцию в конфиге для этого.

Select this for Intel Atom platform. Intel Atom CPUs have an in-order pipelining architecture and thus can benefit from in-order optimized code (requires Intel Atom patch in GCC).

Я у себя так и сделал, когда нетбук настраивал. На нетбуке debian amd64, gcc 4.5 брал из experimental, собирал им ванильное 2.6.32 с помощью make-kpkg.

Бенчмарков не проводил, но вроде бы немного пошустрее стало.

Клево, спасибо, попробую.

Кстати, а как сейчас c amd64? Все уже есть? Флеш работает? :)

>celeron 2 Ghz быстрее атома

Celeron-m 900MHz часто быстрее атома 1.6.

я сравнивала производительность
celeron-m ( 390M ) 1.7 Ghz
и Atom 330 1.6 Ghz ( 2 ядра atom 270 )

по всем параметрам (бенчмарки, скорость компиляции, скорость работы архиваторов) 1 ядро атома показывает половину производительности от Celeron M 1.7, при задействовании двух ядер - производительность сравнивается, HT влияет не особенно сильно, в некоторых задачах ( параллельное сжатие ) может даже замедлять.

возможно у вас другой селерон ?) 390M все же имеет приличной длины кеш в отличие от своих десктопных собратьев

Не могли бы вы показать результат cat /proc/cpuinfo ?

> возможно у вас другой селерон ?

Да, мой селерон намного старее вашего. Он просто морально устарел уже. Я не сомневаюсь, что ваш будет быстрее чем Атом.

$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 28
model name : Intel(R) Atom(TM) CPU N270 @ 1.60GHz
stepping : 2
cpu MHz : 1600.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 xtpr pdcm movbe lahf_lm
bogomips : 3200.18
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 32 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 28
model name : Intel(R) Atom(TM) CPU N270 @ 1.60GHz
stepping : 2
cpu MHz : 1600.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 xtpr pdcm movbe lahf_lm
bogomips : 3200.01
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 32 bits virtual
power management:

> Кстати, а как сейчас c amd64? Все уже есть? Флеш работает? :)

Да, всё работает. Нетбук попался на Atom с поддержкой x86_64, поэтому Debian на нетбуке начал свою жизнь клоном amd64 системы с десктопа :)

Флеш 64-битный. Только радости от этого в свете последних новостей от Adobe, конечно же, не очень много.

С другой стороны, flash плагин у меня бОльшую часть времени всё равно выключен (благо выключить/включить его можно двумя кликами мышки), да и NoScript активно использую, так что незакрытой уязвимости пока боюсь не сильно.

Погуглил - легкого способа миграции 64-битную убунту не нашел. Только полная переустановка, но как-то совсем лень все заново ставить и настраивать. Компилирую ядро под x86. А жаль.

Если не ошибаюсь, то как раз Atom N270 не поддерживает x86_64.

Так что, возможно, и не стоит пробовать 64-битную убунту в этом случае, а продолжать экспериментировать с 32-битной.

flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 xtpr pdcm movbe lahf_lm


lm должно быть , если есть поддержка 64

вот например:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 28
model name : Intel(R) Atom(TM) CPU 330 @ 1.60GHz
stepping : 2
cpu MHz : 1595.795
cache size : 512 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm
bogomips : 3191.78
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 48 bits virtual
power management:

ясно. спасибо, жаба немного отпустила :)

Перекомпилировал ядро. Патч brainfuck никак не улучшил положение дел. Больше даже похоже, что ухудшил.
Вресия, скомпилированная спомощью gcc4.5 и с флагами -march=atom и -mtune=atom вообще не завелась - паникует в самом начале загрузки, выводит непонятные матюки и адреса.

Еще мысли будут?

я собирала ядро на атом с GCC 4.5.1pre и BFS, все работало прилично
BFS добавлял отзывчивости в приложениях, правда у меня нет высокой нагрузки на дисковый IO там

Интересно, что тормозов и подвисаний становится гораздо меньше, когда отключен своп.

Наверное, потому что становится гораздо меньше обращений к диску. Но сами по себе подвисания все равно случаются.

> правда у меня нет высокой нагрузки на дисковый IO там

Копирование файла по медленному каналу - это разве высокая нагрузка? Система ведь простаивает полностью.

а памяти сколько?
вместо дискового swap можно попробовать ramzswap , драйвер включен в staging drivers, ранее он назывался compcache

>Вресия, скомпилированная спомощью gcc4.5 и с флагами -march=atom и -mtune=atom вообще не завелась
а, чо?
у меня такой же проц и гцц 4.5 - в конфиге атом, в мэйкфайле атом -УМВР!

> а памяти сколько?
1 Гиг

вместо дискового swap можно попробовать ramzswap

памяти маловато

>>Вресия, скомпилированная спомощью gcc4.5 и с флагами -march=atom и -mtune=atom вообще не завелась

а, чо?

у меня такой же проц и гцц 4.5 - в конфиге атом, в мэйкфайле атом -УМВР!

А фиг знает чо.
Поскольку моя система вообще не знает о существовании atom, пришлось лезть в arch/x86/Makefile* и ручками прописывать atom вместо generic, поскольку при установке соответствующих переменных среды окружения компилятор в итоге получал в параметрах одновременно и atom, и generic. Мне это не понравилось и полез править. Но все равно не заработало. Может опция «atom» рассчитана на 64-битный проц, хз. В общем не получилось, да и не сильно это критично сейчас. Тут тормоза при копировании файлов - куда более серьезная проблема :)

>Поскольку моя система вообще не знает о существовании atom, пришлось лезть в arch/x86/Makefile* и ручками прописывать atom вместо generic, поскольку при установке соответствующих переменных среды окружения компилятор в итоге получал в параметрах одновременно и atom, и generic

вот поэтому и падает

надо в make menuconfig указывать тип процессора как Atom
и убирать поддержку Generic x86

тогда в Makefile_32.cpu
будет работать вот эта директива

cflags-$(CONFIG_MATOM) += $(call cc-option,-march=atom,$(call cc-option,-march=core2,-march=i686)) \
$(call cc-option,-mtune=atom,$(call cc-option,-mtune=generic))

ahci-->ncq
swappiness=10
vm.page-cluster=0
и т.д. не?

Про атомы

Интересная статья

http://www.ixbt.com/cpu/intel-atom-architecture-3.shtml

> надо в make menuconfig указывать тип процессора как Atom

Делал, не помогает. Возможно это выставляет некоторые опции для gcc4.4, но не arch и mtune.

тогда в Makefile_32.cpu

будет работать вот эта директива

cflags-$(CONFIG_MATOM) += $(call cc-option,-march=atom,$(call cc-option,-march=core2,-march=i686)) \

$(call cc-option,-mtune=atom,$(call cc-option,-mtune=generic))

Ну вот, видимо она и вернула generic. Я так понимаю, что из нескольких вариантов в этой директиве выбирается первый доступный?

> ahci-->ncq

swappiness=10

vm.page-cluster=0

Из этого пробовал только swappiness. Вообще говоря, подозреваю, что моя проблема с этим вообще никак не связана. Например, какое отношение может иметь ncq к записи в nfs шару? Наверное никакого.

смотря какими кусками читать и где эта шара живёт ;)

1) gcc 4.4 не поддерживает -march(mtune)=atom
это прерогативы бэкпорт-версий (редхат например)

2) уверены что не помогает ?

надо в make menuconfig указывать тип процессора как Atom

и убирать поддержку Generic x86

вот это я зачем написала?

-Wa,-mtune=generic это для binutils, убирать не стоит

-mtune=generic появляется если не убрали Generic x86 в конфиге

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

> 1) gcc 4.4 не поддерживает -march(mtune)=atom
Ну это понятно. Похоже мы снова немного о разном говорим :)

2) уверены что не помогает ?

надо в make menuconfig указывать тип процессора как Atom

и убирать поддержку Generic x86

вот это я зачем написала?

Не ругайтесь пожалуйста на меня :) Я честно стараюсь и внимательно читаю. :) Но вот я только не понял, что поддержка generic x86 нужно еще отдельно отключить. А тип процессора я указывал.

-mtune=generic появляется если не убрали Generic x86 в конфиге

Понял. Попробую с отключенным generic еще.

-Wa,-mtune=generic это для binutils, убирать не стоит

Как раз это после долгих и мучительных размышлений и некоторых гуглений я оставил как есть :)

Большое спасибо за терпение и помощь

Сработало, спасибо. На ночь снова поставлю на компиляцию :) Одна вещь только меня смущает. Я где-то (кажется в багтрекере gcc) натолкнулся на жалобу, что с компиляцией под atom не было получено никакого прироста производительности, а даже замедление. На что было отвечено, что это из-за того, что в новой версии дефолтное значение опции -fexcess-precision было изменено, и посоветовали дополнительно указать -fexcess-precision=fast. Сделал пробный запуск компиляции - этой опции не увидел. Стоит ли добавить ее? (в прошлый неудачный раз использовал ее)

ядро я без -fexcess-precision=fast собирала,
а вот для всего остального - включаю

вообще от флажков при сборке ядра особенно приростов ждать не стоит,
тут скорее патчи больше будут иметь значение и настройка параметров sysctl , планировщик.... и т д

Перекомпилировал по-правильному, с флагом "-fexcess-precision=fast". Все равно паникует точно так же.