LINUX.ORG.RU

Вышло ядро Linux 3.3

 ,


0

1

После двух с половиной месяцев разработки увидела свет новая версия ядра Linux 3.3.

В этом выпуске представлены следующие новшества:

  • в сетевой подсистеме:
    • добавлена поддержка агрегирования устройств Ethernet в виртуальное устройство (802.1AX);
    • реализованы необходимые для работы Open vSwitch компоненты;
    • добавлена возможность управления приоритетами сетевых ресурсов в рамках cgroup;
    • представлены наработки, позволяющие контролировать объём данных в очереди на отправку;
    • добавлен контроллер выделяемого объёма памяти для буферов TCP;
    • драйвер Wi-Fi brcmsmac теперь использует bcma для обеспечения работы чипов, которые поддерживают технологию Broadcoms AMBA Interconnect;
    • в драйвер ath9k добавлена поддержка динамического выбора частоты;
    • драйвер hv_netvsc (для Hyper-V) переехал из staging в основной код сетевой подсистемы;
    • в драйвер tg3 добавлена поддержка Broadcom 57766;
    • драйвер virtio-net теперь поддерживает ACPI S4;
    • в AQM добавлен механизм динамического изменения порога отбрасывания кадров в зависимости от объёма трафика;
  • в ФС и подсистеме хранения данных:
    • ext4 получила новый механизм быстрого изменения размера раздела «на лету»;
    • произведено множество улучшений в коде XFS, что позволило значительно увеличить скорость работы с метаданными;
    • в btrfs улучшен код балансировки данных, а также добавлены экспериментальные механизмы проверки целостности во время выполнения операций;
    • в код поддержки софт-RAID добавлена возможность копирования данных с одного носителя на другой с последующим изъятием первого для горячей замены исправных компонентов массива без процедуры перестроения;
    • добавлена поддержка протокола SCSI RDMA;
    • улучшена поддержка SSD;
    • добавлен новый ioctl для предоставления данных о наличии вращающихся компонентов в устройстве хранения данных;
  • в архитектуре и инфраструктуре:
    • реализована начальная поддержка сохранения работающих приложений на диск с целью переноса их на другую систему;
    • в подсистему управления памятью внесены дополнительные исправления (некоторая их часть была принята в 3.2), устраняющие проблемы с производительностью при записи большого объёма данных на медленные носители;
    • улучшена работа контроллера памяти cgroups;
    • в KVM добавлен код для отслеживания производительности;
    • в Xen добавлена поддержка надёжного удаления данных при выполнении операции discard;
    • добавлена поддержка загрузки ядра напрямую с помощью EFI без использования загрузчика;
    • добавлена базовая поддержка спецификации ACPI 5.0;
    • код для ARM теперь поддерживает LPAE, что позволяет на 32-разрядных ARMv7 адресовать больше 4 Гб памяти;
    • в код ARM добавлена подсистема аудита;
    • также в коде ARM реализована базовая поддержка Tegra 3 SoC;
    • произведены многочисленные улучшения в подсистеме криптографии;
    • улучшена поддержка энергосбережения (ASPM);
    • улучшена инфраструктура IOMMU;
  • в драйверах:
    • в nouveau добавлена поддержка новых чипов GeForce;
    • технология энергосбережения RC6 для видеокарт Intel (Ivy Bridge) должна работать правильно без использования самого глубокого состояния (окончательное исправление поддержки RC6 для Sandy Bridge войдёт в 3.4);
    • графический драйвер Poulsbo покинул область staging и перешёл в основной код;
    • в драйвер vga_switcheroo добавлено множество функций для поддержки технологии Optimus;
    • улучшен драйвер Radeon DRM/KMS, в том числе, в части управления памятью;
    • множество драйверов Android внесено в область staging;
    • добавлен механизм разделения буфера DMA несколькими драйверами;
    • драйвер вывода звука, включенный в ALSA, теперь способен передавать данные устройствам в сжатой форме;
    • в драйверах ATA улучшено энергосбережение;
    • в ядро добавлен механизм контроля и управления зарядкой;
  • и, конечно же, в новом ядре исправлено большое число ошибок, а также внесены другие изменения, значимые и не очень, но для которых не осталось места в новости.

Более подробно с нововведениями можно ознакомиться на ресурсе h-online.com: раз, два, три, четыре, а также читая ленту коммитов ядра.

Детальное описание новшеств простым английским языком доступно здесь, здесь, здесь и здесь.

Скачать тарболл с исходниками

Скачать патч на ядро 3.2

>>> Официальный анонс

★★★★★

Последнее исправление: post-factum (всего исправлений: 8)

Ответ на: комментарий от vova7890

«Ждание» должно касаться конкретного процесса который обратился к IO, соответственно, не вешать напрочь всю систему.

Так и есть. На процессы, которые не обращаются в это время к диску, iowait не влияет. Не веришь? Тогда запусти glxgears и посмотри, сколько попугаев она покажет, а затем, не останавливая glxgears, запусти свой find, и ты увидишь, что количество попугаев не изменилось, потому что iowait не влияет на вычислительную нагрузку.

ты не видел как у меня проявляется иоваит баг

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

anonymous
()
Ответ на: комментарий от vova7890

12309 это разные баги, специфичные для разного железа и кривизны рук (прямоты извилин) юзера
сразу видно, что багзиллу ты не читал

anonymous
()
Ответ на: комментарий от anonymous

тогда запусти glxgears и посмотри

попугаи - не показатель. Они не изменятся сильно даже если я запущу компиляцию в 1 поток. Потому-что у меня 2 ядра. Ну допустим оно так, как ты говоришь, почему-же тогда общая нагрузка системы растёт с показателем иоваита? Почему когда у меня чтото свопит проц 100% и иоваит 80%? Если иоваит доходит до 100% может все повиснуть и тупо не отвечать на кнопки. Даже нумлук на клаве не переключается пока его не попустит.

то я может даже смогу тебе его исправить

Я уже даже в маинтернеров ядра не верю, cтолько лет никак не могут... А тут ты анонимус заявляешь такое, я бы был-бы только рад :)

vova7890 ★★★
()
Ответ на: комментарий от vova7890

попугаи - не показатель... Потому-что у меня 2 ядра

Не проблема, можно оба ядра нагрузить. Запусти в одной консоли:
while true; do false; done
а в другой консоли glxgears. А затем посмоти, как изменится количество попугаев, если ты в третьей консоли запустишь find.

почему-же тогда общая нагрузка системы растёт с показателем иоваита?

Какая именно нагрузка? /proc/loadavg? А ты знаешь, что она значит? ;) Load average— это просто среднее количество процессов (потоков) в очереди на выполнение. Чем больше процессов ждут своей очереди, тем больше load. Твой find — это еще один процесс. Он увеличит load ровно на единицу. :)

Почему когда у меня чтото свопит проц 100% и иоваит 80%?

Потому что своп — это обращение к диску. Как и find, своппинг увеличивает iowait. И это тоже увеличивает load, по той же причине, и тоже не влияет на вычислительную нагрузку проца. Но, поскольку это своп, то, очевидно, все программы, которые засвопились, будут висеть, пока не вылезут из свопа. Программа же не может работать, если ее нет в памяти.

Если иоваит доходит до 100% может все повиснуть и тупо не отвечать на кнопки

Не может, проверь. 100% iowait можно получить командой:
dd if=/dev/sda of=/dev/null
При этом тормозить будут только программы, использующие диск.

А тут ты анонимус заявляешь такое, я бы был-бы только рад :)

Проблемы с подвисанием легко диагностировать. Запускаешь в отдельной консоли:
vmstat 1
смотришь, какие числа резко увеличиваются во время подвисания, и сразу видно, в чем причина.

anonymous
()
Ответ на: комментарий от anonymous

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

вот мы и вышли на финишную прямую ;) А теперь я тебе расскажу на пальцах, что из за свопа висит не та программа которая в свопе, а ВСЕ ЯДРО. Я не могу даже переключится в тту, я не могу подвинуть мышку, я не могу НИЧЕГО ДЕЛАТЬ когда своп жрёт ОДНА ПРОГРАММА.

подвисанием

Как я и предпологал, ты не знаешь как у меня проявляется иоваит(?) баг. У меня не подвисания, у меня получасовые фризы. На том же dd, dd - жрёт 100% проца, иоваит около того-же значения, мышка стаёт временно не доступна, о каком glxgears можно говорить если я даже терминал не могу открыть?

vova7890 ★★★
()
Ответ на: комментарий от vova7890

dd - жрёт 100% проца, иоваит около того-же значения, мышка стаёт временно не доступна, я даже терминал не могу открыть

Стой, если ты прямо сейчас просто запускаешь:
dd if=/dev/sda of=/dev/null
то у тебя начинает подвисать мышка? Так давай проверим, в чем причина. Запусти в одной консоли:
cat /proc/interrupts
vmstat 1
И пока vmstat работает, запусти в другой консоли:
dd if=/dev/sda of=/dev/null count=1000000
(count — чтобы он сам остановился, и не вешал систему слишком надолго)
А когда dd отработает, в первой консоли нажми Ctrl+C, чтобы остановить vmstat и снова сделай:
cat /proc/interrupts

Все содержимое первой консоли (оба вывода cat interrupts и vmstat) залей на какой-нибудь pastebin и скинь сюда ссылку, посмотрим, что творится в твоей системе. :)

anonymous
()
Ответ на: комментарий от anonymous

dd if=/dev/sda of=/dev/null count=1000000 не долго работал) Заменил более жостким методом. dd if=/dev/zero of=/tmp/trololo count=1 bs=512M

итерупты - http://codepad.org/XcRKzYiQ vmstat - http://codepad.org/PMLoFUmw

Может все же лучьше потестить на чем нибудть таком, например на новом LibreOffice который на откртии RTF в 800кб жрёт почти полтора гига рамы о_О

vova7890 ★★★
()
Ответ на: комментарий от vova7890

dd if=/dev/sda of=/dev/null count=1000000 не долго работал

Нужно дольше — поставь больше нулей:
dd if=/dev/sda of=/dev/null count=100000000
Такая команда активно использует диск и создает большой iowait. Если такая (именно такая) команда не вызывает подвисаний, то iowait к твоим проблемам отношения не имеет.

Запусти ее, если будет мало, запусти параллельно в нескольких окнах. Убедись, что iowait вырос почти до 100%. Если при этом мыша двигается нормально, окна переключаются, то никакой iowait-баги нет. :)

Заменил более жостким методом. dd if=/dev/zero of=/tmp/trololo count=1 bs=512M

И зачем? Мы же собирались проверить, как влияет работа с диском. Эта команда, что, диск использует? Нет. Она просто сжирает порядка гигабайта памяти, а когда свободная память заканчивается — она начинает вытеснять из памяти в своп другие программы, и другие программы начинают тормозить. Почему тормозить? Потому что программа не может работать, если ее нет в памяти. А почему они оказываются в свопе? Потому что ты этого захотел. :)

Система тут не причем. Она сделала то, что ты сказал ей сделать. Ты сказал, что нужно запустить прогу, которая сожрет кучу памяти, и система это сделала. И iowait тут не причем. Если ты не хочешь, чтобы программы свопились от запуска dd — не запускай dd с дурацкими параметрами. :)

Программам, чтобы работать и не тормозить, нужно находиться в памяти. Из свопа программы работать не могут.

anonymous
()
Ответ на: комментарий от anonymous

И зачем? Мы же собирались проверить

чтобы работать и не тормозить, нужно находиться в памяти. Из свопа программы работать не могут.

Блин, я че на идиота похож? Че это работать не будут, все будет но только работать будет туго одна программа, а не вся система. Виртуальная память позволяет адресовать на физические устройства такие как жесткий диск или что ещё. За счет чего и работает свап. mmap курили и знаем.

На счёт dd if=/dev/zero of=/tmp/trololo count=1 bs=512M Эта комманда будет писать файл в 512 мегабайт, заполненный полностью нулями. Собсно сам файл - /tmp/trololo. Не? А та что ты мне дал, работает только на чтение. Виснет у меня не только ж при чтении, но и при записи.

Ну ладно, сделал две dd if=/dev/sda of=/dev/null count=100000000 Использовать ниче не возможно, ни меню открыть, ни файловый мененджер, местами мышка встаёт колом. Иоваит 60-80%. И это при том, что 2 таких комманды никакого результата правдивого не дадут, так как чтение производится по порядку и головки на жестаке не бегают по всем углам, соответсвенно время ожидания уменьшается. А писать файл + читать чтото - 100% колом становится. И это на новом 3.3 ядром с подкрученым конфигом sysctl.conf без него вообще на любом чихе мышка становилась раком.

vova7890 ★★★
()
Ответ на: комментарий от vova7890

На счёт dd if=/dev/zero of=/tmp/trololo count=1 bs=512M Эта комманда будет писать файл в 512 мегабайт, заполненный полностью нулями.

Да. Но это не все. dd — это программа БЛОЧНОГО копирования. Все операции она выполняет БЛОКАМИ. То есть она сначала считывает целиком 1 блок из первого файла, потом записывает его целиком во второй, затем читает следующий блок из первого файла, и снова пишет его во второй, и т.д. Размер этого блока указывается параметром block size (bs=...), и находится этот блок, ясное дело, в ПАМЯТИ. Поэтому когда ты запускаешь «dd bs=512M...», ты указываешь dd выделить под блок 512 МЕГАБАЙТ ПАМЯТИ.

И это — минимум. В зависимости от других параметров dd может выделить два таких блока (один для чтения, второй для записи). Чтение тоже не идет напрямую с контроллера, а через промежуточные буферы (строка Buffers: в /proc/meminfo), которые тоже находятся в памяти. А если у тебя /tmp смонтировано в tmpfs, то это еще плюс пол гига. Вот сколько памяти уходит на dd с такими дурацкими параметрами. :)

Ну ладно, сделал две dd if=/dev/sda of=/dev/null count=100000000 Использовать ниче не возможно, ни меню открыть, ни файловый мененджер

Конечно. Ведь эти две команды dd сожрали на себя работу с диском. А файловый менеджер наверняка при запуске попытался обратиться к диску. А что с glxgears? Ведь шестеренки точно к диску не обращаются, там — только вычисления. Меняется ли в них количество попугаев при запуске двух dd? ;)

anonymous
()
Ответ на: комментарий от anonymous

Хош я тебе продемонстрирую на видео или я хз. Если уж так хочешь помочь, напиши в жаббер vova7890@jabber.ru. Может после видео поймёшь как и когда оно там фризится... Вот специально зашёл на венду чтоб глянуть чо да как. Начал устанавливать 2 игры одновременно, дефрагментировать паралельно другой раздел и попробовать поюзать систему. И ты знаешь, оно не виснет так, как линукс. Я уж думаю на венду перейти штоле %)

vova7890 ★★★
()
Ответ на: комментарий от vova7890

Хош я тебе продемонстрирую на видео или я хз

Что продемонстрируешь-то? Что у запущенного от рута dd приоритет работы с диском выше, чем у запущенного от юзера файлового менеджера? Я это знаю. И рытаюсь объяснить тебе, почему это так. Так работает (почти любая) операционная система.

Где бы ни была проблема (в кривом железе, кривом ядре, кривых настройках, кривых руках или в голове), ее можно найти и исправить. Но чтобы исправить проблему, надо сначала понять, в чем проблема-то. Ты проверил, влияют ли два dd на количество попугаев в glxgears? ;) Если влияют, то у тебя действительно есть какой-то баг с IO, его надо найти и исправить. А если не влияют, то проблема в другом месте.

Вот специально зашёл на венду чтоб глянуть чо да как. Начал устанавливать 2 игры одновременно, дефрагментировать паралельно другой раздел и попробовать поюзать систему. И ты знаешь, оно не виснет так, как линукс.

Теперь попробуй загрузить линух и начать ставить в вайне те же самые две игры. И тоже виснуть не будет.

А в винде попробуй от админа запустить два dd под cygwin-ом (или свой один dd bs=512M), и походить при этом в проводнике по файловой системе. :)

Да, кстати, у dd под линухом еще и скорость будет выше, чем под виндой.

anonymous
()
Ответ на: комментарий от anonymous

И тоже виснуть не будет.

ошибаешься, виснет так, чо я осавляю комп в покое пока оно не установится.

А в винде попробуй от админа запустить два dd под cygwin-ом

попробую :)

vova7890 ★★★
()
Ответ на: комментарий от anonymous

$ dd.exe if=/dev/zero of=/tmp/trololo bs=256M count=1 1+0 записей считано 1+0 записей написано скопировано 268435456 байт (268 MB), 3,99755 c, 67,1 MB/c

никаких висов, ничуть не запнулось, даже браузер запустился нормально, и работал. В линуксе же я даже менюшку открыть не могу. Эт во первых. Во сторых, скорость записи, в линуксе у меня было около 30 MB/c сдесь же все 67, учитывая что в говновенде нету(?) нормального кеширования фс.

vova7890 ★★★
()
Ответ на: комментарий от anonymous

два dd if=/dev/sda of=/dev/null count=100000000 грузят проц на 12% и соверершенно не мешают работе. Хоть и жестак там трещит чуть не вылетает.

vova7890 ★★★
()
Ответ на: комментарий от anonymous

кстате на венде я юзал всякую фигню, открывал проводник и т.п. когда дд делал. Вот результат на линуксе тоже всякую фигню делал

# dd if=/dev/zero of=/tmp/trololo bs=256M count=1 1+0 записей считано 1+0 записей написано скопировано 268435456 байт (268 MB), 16,7159 c, 16,1 MB/c

vova7890 ★★★
()
Ответ на: комментарий от vova7890

два dd if=/dev/sda of=/dev/null count=100000000 грузят проц на 12%

Линукс и винда считают разные ресурсы. Нет смысла сравнивать разные проценты.

dd.exe if=/dev/zero of=/tmp/trololo bs=256M count=1

Почему 256, а не 512 или даже 1024?

dd if=/dev/zero of=/tmp/trololo bs=256M count=1 ... 16,1 MB/c

У меня все наоборот, в винде 44МБ/с, а в линуксе:
$ dd if=/dev/zero of=/tmp/trololo bs=256M count=1
скопировано 268435456 байт (268 MB), 1,32748 c, 202 MB/c
«Всякую фигню» я сделать не успеваю.

Но мы ушли от темы. Какую именно проблему ты хочешь исправить? На вопрос про glxgears ты не ответил, видимо, с ним все в порядке, и с io тоже. Тогда скажи еще раз что тебя не устраивает? Опиши саму проблему, и назови те действия, которые ты выполняешь, чтобы ее вызвать. Я не смогу помочь, если ты не скажешь, в чем нужна помощь.

Например, если проблема в том, что программы свопятся, то решение:
swapoff -a
кстати, попробуй, вдруг все висы исчезнут? На вопрос «куда делась вся память» помогут ответить команды: free, df (смотреть на tmpfs) и top (Shift+M отсортирует программы по памяти).

anonymous
()
Ответ на: комментарий от anonymous

без свапа пробоваляяяя - ещё хуже. Про глхгеарс ещё раз повторяю, нет никаого смысла тестировать на нём:

1. Большая часть работы выполняется на видеокарте 2. Операции ИО, как я уже сказал, вешают _весь_ гуй в том числе и попугаии в глхгеарс падают с 5400 до 1000 либо меньше.

С ио нифига не в порядке.

dd if=/dev/zero of=/tmp/trololo bs=256M count=1
скопировано 268435456 байт (268 MB), 1,32748 c, 202 MB/c

дык, кеш почисти, ёпт. Если ты не видишь проблемы, и что она явна связано с ио, ка ты мне сможешь помочь?

vova7890 ★★★
()
Ответ на: комментарий от vova7890

Если ты не видишь проблемы, и что она явна связано с ио, ка ты мне сможешь помочь?

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

anonymous
()
Ответ на: комментарий от anonymous

Я не сопротивляюсь, я просто активно хочу докричатся до собеседника, что проблема именно в подсистеме ИО, так-как только при её использовании начинают валится непонятные фризы системы. Если честно, у меня подозрения на семафоры. Возможно где-то, какой-то семафор не правильно срабатывает(в зависимости от оборудования?) и приводит к тому, что запись, к примеру на флешку, до недавнего времени вешала иксы. И тут не загрузка проца виновата, так-как даже gcc -j100 не сможет вот так резко просто остановить процесс. Сейчас конечно получьше, но всё-же не идеально. Попрежнему запись на флеш немного подвешивает систему. Например про планировщик процессов линукса я могу сказать что он неповторим. При жесткой нагрузке на проц, планировщик остаётся справедливым к остальным процессам, и даже если в фоне gcc -j3, я иногда забываю что у меня там что-то компилируется, потому-что не чуствую тормозов системы(в отличии от вендового планировщика). Но вот подсистема ИО оставляет желать лучьшего...

vova7890 ★★★
()
Ответ на: комментарий от vova7890

Могу поделиться своими впечатлениями о новом ядре.

На 3.2.6 невозможно было что-либо делать, пока шло копирование на usb-hdd, например, фильм ~10ГБ; Гуй просто застывал до тех пор, пока не закончится копирование.

В новом ядре 3.3.0 изменил настройку (ибо с описанное выше положение совсем не устраивало) CONFIG_SLAB, вместо *_SLUB. И выбрал No Forced Preemption (Server) вместо Preemptible Kernel (Low-Latency Desktop).

В результате, копирование нормализовалось, отзывчивость повысилась: при копировании спокойно можно открывать окошки, вызывать меню, менять вкладки в опере и т.д., для теста одновременно запускал ещё и vmware, физически расположенную на nfs - всё пучком.

Причём, что интересно, если с No Forced Preemption (Server) фризов не было, то с Voluntary Kernel Preemption (Desktop) фризы начали появляться. Хоть и не такие как с 3.2.6, но всё же... Думаю, что где-то тут и кроется ошибка.

P.S. Debian amd64, Phenom II X6 1100T

Jurik_Phys ★★★★★
()
Ответ на: комментарий от vova7890

кеш почисти, ёпт

Что почистить, /dev/zero?

Если ты не видишь проблемы, ка ты мне сможешь помочь?

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

1. Сразу после того, как ты загружаешь систему — у тебя все работает нормально, мышка двигается, окна перетамкиваются, или с самого начала, после загрузки начинаются висы?

2. Если сразу после загрузки все нормально, то какое действие у тебя надо выполнить (какую команду надо выполнить, чтобы вызвать висы?

anonymous
()
Ответ на: комментарий от Jurik_Phys

На 3.2.6 невозможно было что-либо делать, пока шло копирование на usb-hdd

А это старое ядро еще осталось, то на котором была проблема с копированием? Есть у меня догадка, что причина была не в ядре, а в настройках балансировки прерываний, это часто встречается на дебианах и убунтах. Проверяется так:

1. Загрузить старое ядро, у которого проблема была.

2. Запустить копирование на usb-hdd, убедиться, что проблема есть (если это ­— та проблема, то даже курсор мыши не будет двигаться, и копироваться будет довольно медленно)

3. Перенастроить обработку всех прерываний на один проц. Для этого от рута:
for f in /proc/irq/*/smp_affinity; do echo 1 > $f; done

4. Снова запустить то же самое копирование.

Ничего не виснет и скорость возросла?

anonymous
()

Мой коммент короткий:

Мну уже это ядро хотеть себе..

muteki_okami
()
Ответ на: комментарий от Jurik_Phys

Я когда-то тоже пробовал собирать с оптимизацией на сервер. Помоему не помогло, я не помню уже. Но, на сколько я знаю, при выборе Server, увеличивается квант времени для всех тасков. Тобишь что-то внатуре со щедуллером и обработкой прерываний не так. Может прерывания от жестака вылетают на каждый круг щедуллера(то это подтверждает баговость nforce). Что и вешает все на мертво. Я в общем не знаю, я не настолько умный чтобы в ядре что-то ковырять) Но как почему оно тогда нормально работает на bsd и винде, вот в чем вопрос.

vova7890 ★★★
()
Ответ на: комментарий от anonymous

Что почистить, /dev/zero?

кеш работает не только на чтение но и на запись? Тобишь запись в /tmp/trololo задействует кеш...

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

2. Ну например, запустить чтото тяжолое, оперу к примеру. До свапа она не дотягивает, но при запуске оперы контексты и менюшки открываются туговато. Если выполнить dd - фризы. Я ж помоему рассказывал про баг LibreOffice? Когда он на 800килобайтовую rtf-ку сожрал полтора гига рамы. Он весь в своп залез, и я сидел пол часа(засекал) пока он поностью не выгрузится из рамы/свопа.

vova7890 ★★★
()
Ответ на: комментарий от anonymous

Собрал из старых исходников ядро и начал тестировать: Файл 2803059MB ***.BDRip.x264.mkv, копировал из /home/user/ на usb-hdd через mc из состояния холодного старта:

Итоги:

linux 3.2.6:
50% скопировано V = 15.07МБ/с;
linux 3.2.6; + "for f in /proc/irq/*/smp_affinity; do echo 1 > $f; done"
50% скопировано V = 15.42МБ/c;
linux 3.3.0
50% скопировано V = 17.7МБ/с;

Заставить систему 3.2.6 тормозить не удалось. Наверное, из-за того, что система сразу после запуска.Большой разницы в скорости записи на usb-hdd для 3.2.6 не заметно, 3.3.0 немного быстрее (хотя как посмотреть прирост скорости более 10%).

Если верить conky, то в 3.2.6 скорость чтения файла держалась всё время примерно одинаковой на уровне ~16MБ/с, тогда как в 3.3.0 чтение происходило на скорости ~23МБ/с, но она временно падала до ~2МБ/c, затем было восстановление. Похожее происходило и на ядре 3.2.6 c irq-шаманством.

В общем, мой вывод такой, что всё же дело в ядре. Ядро 3.3.0 или получше настроено у меня (см.выше), или само по себе немного быстрее.

Jurik_Phys ★★★★★
()
Ответ на: комментарий от Jurik_Phys

Заставить систему 3.2.6 тормозить не удалось.

Жаль. Значит либо это другая проблема, либо настройки изменились. Проблема баллансировки очень заметна. Вылазит обычно при записи на USB или при передаче по гигабитной сети. В vmstat-е при этом видно всплеск, а в /proc/interrupts видно, что прерывания от USB/сетевухи обрабатываются на нескольких cpu. И из-за постоянных переключений обработки с одного cpu на другой и возникают висы.

Все равно, спасибо за проверку и подробный отчет.

anonymous
()
Ответ на: комментарий от vova7890

1. После загрузки все ништяком.

Ок, понятно.

Дальше ты описал несколько разных проблем, ни одна из которых не связана с ядром. Я объясню каждую отдельно.

2. запустить чтото тяжолое, оперу к примеру. До свапа она не дотягивает, но при запуске оперы контексты и менюшки открываются туговато.

Ок, проблема 1: при запуске оперы менюшки долго открываются. У этой проблемы могут быть две причины:
а. Опера при запуске активно использует CPU, и остальные программы работают медленнее, в том числе и менюшки.
б. Опера при запуске активно испрльзует диск, и если для открытия менюшки тоже нужно обращение к диску (чтобы считать с диска список пунктов), то менюшка будет открываться медленнее, потому что диск занят оперой.
Проверить, какая это из причин, можно, запустив до оперы в консоли «vmstat 1», и посмотрев, какие числа вырастут при запуске оперы.
Решение: запускать оперу с пониженным приоритетом:
nice -n 10 opera
Тогда ядро при выборе между оперой и менюшкой, отдаст приоритет менюшке.

Если выполнить dd - фризы

dd с какими параметрами? Сколько при этом какой памяти (команда free) до запуска dd? А сколько памяти после запуска?

Я ж помоему рассказывал про баг LibreOffice?

Ок, проблема 2: офис жрет много памяти. Это — баг в офисе, и я не могу с ним помочь. Но ты — можешь. Открой баг на багтрекере LibreOffice, напиши, что офис жрет полтора гига и приаттач к нему свою rtf-ку. Если этого не сделать, то разработчики не узнают о проблеме.

anonymous
()
Ответ на: комментарий от anonymous

Да ты совсем не понимаешь, из за чего эти лаги менюшек. Я ещё раз повторяю, у меня __2__ ядра. Опера при загрузке грузит одно ядро, спу тут вообще не причем. Тут что-то кудато палки в колёса ставит что оно не тормозно открывается а тупо неокрывается @ палку вытащили @ сразу-же открылось... Баг либра я вообще для примера указал, я выделил, что он жрёт дохрена рамы, что способствует свапингу. За щет чего и вешается все на пол часа. Его я потом вышлю. Ладно кароче, это все бестолку... Спасиба, что пытался помочь :)

vova7890 ★★★
()
Ответ на: комментарий от Jurik_Phys

Собрал 3.3 с оптимизацией на сервер, таймер на 300 Hz. При IO операциях отзывчивость на глаз увеличилась. Запускаю ту-же оперу, менюшки открываются быстро, паралельно могу открыть ещё что нибудь. Интересно, если таймер на самую маленькую частоту поставить :)

vova7890 ★★★
()
Ответ на: комментарий от ZenitharChampion

Проблема баллансировки очень заметна. Вылазит обычно при записи на USB или при передаче по гигабитной сети.

Хм, именно при таком раскладе на 3.2.6 ком и вставал колом: копировал с nfs по гигабитной сети на usb-hdd; Если вдруг снова появится, попробую предложенный костыль. Но, я так понял, что после перезапуска программы, костыль надо перезапускать, что возможно только для теста.

P.S. гугл по этой проблеме толком ничего не говорит. Нашёл описание про демон irqbalance. Должен ли он помочь решить данную проблему?

Jurik_Phys ★★★★★
()
Ответ на: комментарий от ZenitharChampion

2.803.059 Mb... 2 терабайта?

Ой, опечатался... ls -A выдало без единиц измерения, неподумавши написал мегабайты... 2 ГБ, конечно.

Jurik_Phys ★★★★★
()
Ответ на: комментарий от vova7890

Да ты совсем не понимаешь, из за чего эти лаги менюшек.

Не понимаю, потому что у меня лагов нет. Поэтому я тебе и написал, что для того, чтобы узнать, из-за чего лаги, запусти «vmstat 1» и посмотри, какие числа сильно меняются при появлении лагов.

Опера при загрузке грузит одно ядро, спу тут вообще не причем.

Откуда ты знаешь? Ты смотрел vmstat? ;)

Тут что-то кудато палки в колёса ставит

И чтобы узнать, что и куда ставит палки в колеса, неплохо бы посмотреть vmstat. Для особо умных есть systemtap, но я боюсь, что не осилю объяснить, как им пользоваться.

Давай разделим все твои лаги на две части: лаги связанные со свопом, и лаги, которые со свопом не связаны. А потом будем решать их по-отдельности. Чтобы определить, связана проблема со свопом или нет, посмотри что во время проблемы пишет «vmstat 1» в колонках si и so (swap-in и swap-out). Если в этих колонках не нули, то проблема связана со свопом.

Затем, когда ты это определишь, назови те проблемы, которые не связаны со свопом, и мы попробуем их решить. :)

За щет чего и вешается все на пол часа.

Все, или только те программы, которые оказались в свопе? Ведь иксы — это тоже программа, которую тоже можно загнать в своп, и тогда графика будет тормозить. Кстати, ты вообще понимаешь, почему программа, которую вытеснили из памяти в своп, тормозит и виснет? Или ты думаешь, что попадание в своп не влияет на скорость программ?

anonymous
()
Ответ на: комментарий от Jurik_Phys

я так понял, что после перезапуска программы, костыль надо перезапускать

Нет, после перезапуска программы — не надо. Только после перезапуска компа. Там меняются текущие настройки ядра, и они сохранятся до ребута, если только какая-то другая программа их не поменяет.

Этот for — для теста, он позволяет сразу проверить, в этом дело или нет. Если подвисание вызвано распределением прерываний, то после этого for-а подвисание должно тут же исчезнуть. Но в нем меняются только текущие настройки, после ребута они не сохранятся, если не вписать его в rc.local, например.

Нашёл описание про демон irqbalance. Должен ли он помочь решить данную проблему?

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

anonymous
()
Ответ на: комментарий от vova7890

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

anonymous
()
Ответ на: комментарий от anonymous

23: 272 82868 IO-APIC-fasteoi ahci

23й итерупт ahci(мой жестак выставлен в биосе как ahci), так вот при записи на жестак итерупты летят с такой скоростью, меньше милисекунды наверно. Это нормально?

vova7890 ★★★
()

Кароче, все кто писал что BFS уменьшает последствия iowait бага - слоупоки. Вернул обратно CFS - интеррупты вернулись в норму и вылетают не так часто как на бфс, а то быстрей таймера щедулера летят блин... Да и cfs заметно лучьше работает при io операциях чем bfs(кой от любого чиха io вводил систему в ступор).

vova7890 ★★★
()
Ответ на: комментарий от vova7890

мой жестак выставлен в биосе как ahci

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

при записи на жестак итерупты летят с такой скоростью, меньше милисекунды наверно. Это нормально?

При записи на диск может быть много прерываний. Само по себе это ничего не значит. Прерываний вообще много. Даже система, которая вроде ничего не делает, может обрабатывать тысячи прерываний в секунду. Количество обрабатываемых прерываний можно посмотреть в «vmstat 1» в колонке «in» (interrupts).

anonymous
()
Ответ на: комментарий от anonymous

смена режимов ничего не даёт. Прерываний то много, но не с такой скоростью... Шо щедуллер на всех забивает и обрабатывает только итерапты(особенно хорошо видно это на примере BFS). Говорили что это бажный чип nforce, который слишком часто срал прерывания, что приводило к таким вот фризам. У меня тот самый злорастный нфорс, но на последнем ядре с CFS планировщиком, прерывания нормально постапуют.

vova7890 ★★★
()
Ответ на: комментарий от vova7890

Говорили что это бажный чип nforce, который слишком часто срал прерывания

Это вызывало проблемы при неправильной балансировке, и решалось for-ом, описанным на несколько комментариев выше.

Вообще-то, не так уж и много прерываний приходит тебе от ahci. Если посмотреть на /proc/interrupts, что ты раньше выкладывал, у тебя 47:eth1 и 21:ohci_hcd:usb4,snd_hda_intel генерируют раз в 10 больше прерываний, чем ahci. Кстати, например, некоторые USB-мыши генерируют порядка тысячи прерываний в секунду. Но, опять-таки, проблемы это вызывает только при неправильной баллансировке прерываний.

anonymous
()
Ответ на: комментарий от anonymous

прерывания выскакивают всегда на втором ядре. То что я давал cat итеруптов, было на CFS. На bfs итерупты летят на уровне системного таймера гдето. Что и порождает дикие висы. Балансировка не спасает. На счет eth1 там передельно ясно почему итерупты выскакивают. Потому, что у меня инет через сетевуху, и радио поёт постоянно. Вот она и шлёт итерупты. Но не с такой скоростью как слал нфорс с bfs планировщиком. Но вот с cfs все в порядке, и все равно от ступоров оно полностью не спасает. Сейчас сижу на самопальном ведре собранном для серверной конфигурации, таймер выставлен на минимум - 100 гц.

vova7890 ★★★
()

В тестинге арча уже появилось 3.3.1

Через день-другой будет в core :)

uniqwert
()

в ядро добавлен механизм контроля и управления зарядкой;

Какую опцию в конфиге ядра нужно включить? Как использовать?

hope13 ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.