После двух месяцев разработки Линус Торвальдс представил (https://lkml.org/lkml/2014/6/8/70) релиз ядра Linux 3.15 (http://kernel.org). Отмечается, что выпуск 3.15 является одним самых больших по размеру изменений за всю историю проекта. При этом, изменения не связаны с реализацией каких-то отдельных значительных новшеств, а обусловлены принятием большого числа мелких доработок и внутренних переделок.
В новую версию принято более 12 тысяч исправлений от 1400 разработчиков, размер патча - 57 Мб (изменения затронули 11428 файлов, добавлено 932468 строк кода, удалено 571846 строк). Около 44% всех представленных в 3.15
изменений связаны с драйверами устройств, примерно 18% изменений имеют
отношение к обновлению кода специфичного для аппаратных архитектур, 12% связано с сетевым стеком, 4% - файловыми системами и 4% c внутренними подсистемами ядра.Из наиболее интересных новшеств (http://kernelnewbies.org/Linux_3.15) можно отметить:
-
Память и системные сервисы
- Включены (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...) наработки компании Intel по ускорению процесса возврата из ждущего режима на системах с дисковыми контроллерами SATA. Благодаря организации асинхронного одновременного вывода из ждущего режима дисков и прочих устройств время пробуждения ноутбуков удалось сократить (https://01.org/suspendresume/blogs/tebrandt/2013/hard-disk-r...) в 7-12 раз. Например, время вывода из ждущего режима компьютера на базе Intel Core i7 3960X уменьшилось с 11.6 до 1.1 секунд (в 10.5 раз), ноутбука на базе Intel Core i7 3770 с 5.4 до 0.45 секунд (в 12 раз), а ноутбука на базе Intel Core i7 4770S с 5.4 до 0.69 секунд (в 7.8 раз). Ранее узким местом возврата из спящего режима было ожидание готовности SATA-контроллеров после поступления питания. Теперь, драйвер дискового контроллера мгновенно возвращает управление, не дожидаясь запуска контроллера, что позволяет ядру выполнить другие операции возврата из спящего режима, не связанные с дисковым вводом/выводом (например, инициализировать графическую подситему), во время пробуждения SATA-контроллера.
- Добавлены (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...) подготовленные в рамках проекта LLVMLinux (http://llvm.linuxfoundation.org) новые патчи для улучшения сборки с использованием компилятора Clang. Пока цель проекта ещё не достигнута и ядро из коробки не может быть собрано без дополнительных патчей при помощи Clang. Недостающие патчи планируется интегрировать в ядро 3.16;- Реализация (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...) смешанного режима EFI (EFI mixed mode), который позволяет загрузить 64-разрядное ядро из 32-разрядной прошивки, что может потребоваться при работе загрузчиков с поддержкой протокола EFI Handover;
- В подсистему обеспечения эффективного управления питанием (pm_qos) добавлена поддержка режима "терпимой отзывчивости" (DEV_PM_QOS_LATENCY_TOLERANCE) с реализацией механизма передачи устройству данных о требуемой отзывчивости, что может быть использовано для предотвращения ввода устройства в слишком глубокие режимы энергосбережения, если выставленное QoS-значение требует оперативного пробуждения;
- Добавлен системный вызов renameat2, предоставляющий средства для атомарной замены имён двух файлов (первый файл переименовывается во второй, а второй в первый). Также добавлен флаг RENAME_NOREPLACE, при котором операция переименования не приводит к замене уже существующего файла;
- Поддержка приватных для файлов POSIX-блокировок (http://lwn.net/Articles/586904/) (file-private POSIX locks), предоставляющих более приемлемый для многопоточных программ API для организации блокировок доступа к файлам, комбинирующий возможности механизмов BSD- и POSIX- блокировок. Основное отличие от классических POSIX-блокировок заключается во владельце блокировки: POSIX-блокировкой владеет процесс, а приватная POSIX-блокировка принадлежит открытому файлу;
- Значительно улучшена (http://lwn.net/Articles/495543/) работа системы управления памятью в плане создания эвристических методов для балансировки между active/inactive списками в ситуации кратковременного вывода страниц из памяти. Включен (http://lwn.net/Articles/589475/) набор патчей для оптимизации VMA-кэширования (Virtual Memory Areas) в привязке к отдельным нитям.
- В блочном устройстве zRAM, применяемом для хранения раздела подкачки в ОЗУ в сжатом виде, обеспечена поддержка метода сжатия LZ4;
-
Сетевая подсистема
- В интерфейс фильтрации пакетов ipset добавлен новый тип наборов "hash:ip,mark" для сопоставления с пакетами, на которые установлены определённые метки, добавленные при помощи высокоуровневых утилит;- Переписана (http://lwn.net/Articles/593476/#internals) реализация JIT-компилятора для кода BPF с задействованием нового набора инструкций BPF;
-
Дисковая подсистема, ввод/вывод и файловые системы
- В подсистему FUSE (filesystems in user space) добавлена поддержка кэширования с отложенной записью (writeback), которое позволяет поднять производительность в условиях интенсивность записи;- В Device Mapper добавлен новый модуль "dm-era (http://lwn.net/Articles/593668/)", предназначенный для поддержания списка блоков, изменённых за определённый пользователем промежуток времени. С практической стороны, при помощи dm-era можно отслеживать изменённые блоки для систем резервного копирования или частично сбрасывать кэш для восстановления состояния после отката на снапшот;
- Добавлен драйвер, позволяющий представить Flash-накопитель в виде блочного устройства (пока только в режиме только для чтения), что позволяет использовать любую файловую систему поверх raw Flash-устройства;
- В файловые системы ext4 и XFS в системный вызов fallocate() добавлена (http://lwn.net/Articles/589260/) поддержка операций FALLOC_FL_ZERO_RANGE и FALLOC_FL_COLLAPSE_RANGE, позволяющего предварительно выделять место под файлы с определением нулевых и неопределённых (недоступных на чтение до заполнения) диапазонов;
- Для файловой системы XFS реализована поддержка флага O_TMPFILE;
- Удалена реализация /proc/device-tree со сведениями Device Tree. Вместо /proc/device-tree следует использовать область /sys/firmware/devicetree/base, символической ссылкой на которую теперь является /proc/device-tree;-
Виртуализация и безопасность- Для архитектуры x86 теперь не допускается создание 16-разрядых сегментов при работе в 64-разрядном режиме. Изменение внесено так как использование 16-разрядых сегментов может привести к потенциальным проблемам с безопасностью, связанным с утечкой информации из ядра. C небольшой вероятностью данное изменение может нарушить работоспособность некоторых приложений в пространстве пользователя, в частности, перестанут работать 16-разрядные приложения, наличие которых под большим вопросом.
-
Аппаратные архитектуры- Поддержка MIPS-систем на базе архитектуры CPS (Coherent Processing System);
- Для архитектуры ARM добавлена поддержка системы контрольных проверок uprobes (userspace probes), используемой для анализа поведения выполняемых в пространстве пользователя приложений;
- Для архитектуры Tile добавлена поддержка подсистемы perf events;
- Прекращена поддержка устаревших субархитектур x86: Unisys ES7000, IBM Summit/EXA, SGI Visual Workstation, NUMAQ.
-
Оборудование- Поддержка процессоров Loongson 3, а также систем Marvell Armada 375, 380 и 385, Broadcom BCM470X и BCM5301X;
- Поддержка SATA-контроллеров Allwinner A10/A20 AHCI, APM X-Gene AHCI и DaVinci DA850 AHCI;
URL: https://lkml.org/lkml/2014/6/8/70
Новость: http://www.opennet.me/opennews/art.shtml?num=39959
>драйвер дискового контроллера мгновенно возвращает управление, не дожидаясь запуска контроллеразвучит как будущая дыра
Почему? Если диск отвалится, не всё ли равно, как это будет выглядить?
> звучит как будущая дыра
> В предоставляемом ядром генераторе псевдослучайных чисел в качестве одного из дополнительных источников энтропии обеспечена поддержка данных, получаемых через инструкцию RDSEED, появившуюся в процессорах Intel Broadwell;Закладка АНБ
Это только один из источников энтропии. Вряд ли это может быть закладкой АНБ. На одной такой закладке далеко не уехать.
> Закладка АНБЗакладкой оно станет если использовать это как упыри из OpenSSL - напрямую подавая на выход то что это барахло выдает. А если вывод этого нечто подмешивать к куче других случайных величин - ничего страшного не произойдет: в хучшем случае (полностью предсказуемый вывод) энтропии просто не станет больше. В лучшем (если закладок все-таки нет) энтропии станет немного больше.
После зонда в виде СОРМ-1/2 не всё ли тебе равно?
СОРМ не следит за жителями/госслужащими других стран, в отличие от.
это сугубо потому, что через РФ - не проходит 90% телекоммуникаций, в отличие от США.
и не разрабаытвается и производится 100% и 30% харда и практически ВЕСЬ софт.
будь иначе - разница бы была ничтожна. практически.
> будь иначе - разница бы была ничтожна. практически.А "бы" в этом мире не считается...
> После зонда в виде СОРМ-1/2 не всё ли тебе равно?А мне вот что интересно: а тебе по кайфу быть АНБшной подстилкой и все их гадости выгораживать? Или тебе пропаганда мозг окончательно сожpaла? Настолько что соображалка совсем отпала? А то с СОРМом есть одна "небольшая" закавывка: оно может и хотело бы кусаться, но увы - беззубое. Не производят в России процессоров, которые у тебя или у меня в компьютере будут стоять. И да, никакой COPМ не сможет ничего сделать с end-to-end шифрованием. Прикинь, да?
Торт.
zram пользую, i7 то же.
i7 и zram - разные вещи.
i7 не есть то же, что и zram;
или пробел.
На убунту14 как поставить?
Как всегда, просто:# make menuconfig
# make
# make modules
# make modules_install
# cp arch/x86_64/boot/bzImage /boot/vmlinuz-3.15[сообщение отредактировано модератором]
гы, ыксперд хренов
для дебиановых 100 лет как есть target deb-pkgmake menuconfig
make deb-pkgполучаем готовые деб пакеты.
dpkg -i эти самые пакеты.
я делаю так:
make oldconfig
INSTALL_MOD_STRIP=1 CONCURRENCY_LEVEL=4 fakeroot make-kpkg --initrd kernel_image kernel_headers
...хотя какая разница))
А можно скачать такое и даже не компилить:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.15-utopic/
у меня нестандартный конфиг =)
> у меня нестандартный конфиг =)А у вопрошавшего скорее всего стандартный, раз такие вопросы задает.
Как обычно -- подождать, пока соберут другие:
http://kernel.ubuntu.com/~kernel-ppa/
Уже:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.15-utopic/
from here http://kernel.ubuntu.com/~kernel-ppa/mainline/
для убунты есть целый PPA со свежими ядрами уже собранными от карнел орг.
не получается добавить ссылку выше как репозиторий
> не получается добавить ссылку выше как репозиторий
делаю add-apt-repository http://kernel.ubuntu.com/~kernel-ppa/mainline, в aptitude update потом 404 ошибка
> делаю add-apt-repository http://kernel.ubuntu.com/~kernel-ppa/mainline, в aptitude
> update потом 404 ошибкаПотому что это не репозиторий, баклан. Это просто HTTP сервер где ядра лежат. Зачем его PPA назвали - не знаю, наверное как раз чтобы наивных чукотских юношей смущать. Скачать надо три файла. Headers под свою архитектуру, headers которые общие для всех архитектур и image под свою архитектуру. Далее dpkg -i <эти файлы>. Проще всего скачать все в отдельную диру и сказать dpkg -i *.deb находясь в этой дире. Но вообще с такими познаниями лучше не экспериментировать с ядрами. А то мало ли, система например не загрузится...
> А то мало ли, система например не загрузится...это для него будет благо.
Сам ты баклан.
> Сам ты баклан.Я не добавляю что попало как PPA, так что увы. Нет, убунтуи конечно прикольно придумали назвать PPA то что им не является, но если честно, я такие приколы на опеннете впервые вижу :). Раньше народ вроде допирал сходить по ссылке и по содержимому осознать что это не репа.
Сыну ты бы тоже в таком тоне объяснял?
> Сыну ты бы тоже в таком тоне объяснял?то есть, ты ставишь себя на один уровень с недееспособными? ну, хоть сам признаёшься.
Толсто.
> Толсто.это логика, мальчик.
>> Толсто.
> это логика, мальчик.мальчиком быть лучше, чем девочкой.
но вы - видимо, несогласны и с этим.
увы.
>>> Толсто.
>> это логика, мальчик.
> мальчиком быть лучше, чем девочкой.Ты проверяло?
> мальчиком быть лучше, чем девочкой.спасибо за наглядную демонстрацию того, что ты и логика — явления, не имеющие ничего общего.
> Сыну ты бы тоже в таком тоне объяснял?Ну вы то мне не сын. А тон обусловлен нежеланием индивида включать мозг. Если навигатор говорит "поверните налево!" - нехило бы посмотреть глазами что там творится. А то можно и в обрыв уехать, если клювом щелкать и слепо верить любой информации поданной на вход. Прецеденты были. Поэтому узрев URL который не работает - нехило бы посмотреть на него глазами и понять что там вообще находится.
По видеодровам ничего нового?
> По видеодровам ничего нового?* Graphics: NXP PTN3460 DisplayPort-to-LVDS bridges, Samsung EXYNOS DRM MIPI-DSI devices, LD9040 RGB/SPI panels, and S6E8AA0 DSI video mode panels.
* Video4Linux: Micronas DRX-J demodulators, TI LM3646 dual flash devices, ImgTec infrared decoders, Mirics MSi001 silicon tuners, Realtek RTL2832 silicon tuners, Samsung S5K6A3 sensors, and EXYNOS4x12 FIMC-IS ISP direct DMA capture interfaces.
> По видеодровам ничего нового?Смотря что считать за новое и смотря какие видеодрайвера вас интересуют. Из groundbreaking changes ничего особого. Из фиксов ... ну вон в radeon например фиксов порядочно есть. Просто они сугубо технические и исправляют баги, etc. Юзеру это малозаметно, кроме случаев если вас кусал некий баг.
А что с этим?
http://www.opennet.me/opennews/art.shtml?num=39944
Выпустили ядро без патча?
Merge futex fixes from Thomas Gleixner:
"So with more awake and less futex wreckaged brain, I went through my
list of points again and came up with the following 4 patches.1) Prevent pi requeueing on the same futex
I kept Kees check for uaddr1 == uaddr2 as a early check for private
futexes and added a key comparison to both futex_requeue and
futex_wait_requeue_pi.Sebastian, sorry for the confusion yesterday night. I really
misunderstood your question.You are right the check is pointless for shared futexes where the
same physical address is mapped to two different virtual addresses.2) Sanity check atomic acquisiton in futex_lock_pi_atomic
That's basically what Darren suggested.
I just simplified it to use futex_top_waiter() to find kernel
internal state. If state is found return -EINVAL and do not bother
to fix up the user space variable. It's corrupted already.3) Ensure state consistency in futex_unlock_pi
The code is silly versus the owner died bit. There is no point to
preserve it on unlock when the user space thread owns the futex.What's worse is that it does not update the user space value when
the owner died bit is set. So the kernel itself creates observable
inconsistency.Another "optimization" is to retry an atomic unlock. That's
pointless as in a sane environment user space would not call into
that code if it could have unlocked it atomically. So we always
check whether there is kernel state around and only if there is
none, we do the unlock by setting the user space value to 0.4) Sanitize lookup_pi_state
lookup_pi_state is ambigous about TID == 0 in the user space value.
This can be a valid state even if there is kernel state on this
uaddr, but we miss a few corner case checks.I tried to come up with a smaller solution hacking the checks into
the current cruft, but it turned out to be ugly as hell and I got
more confused than I was before. So I rewrote the sanity checks
along the state documentation with awful lots of commentry"* emailed patches from Thomas Gleixner <tglx@linutronix.de>:
futex: Make lookup_pi_state more robust
futex: Always cleanup owner tid in unlock_pi
futex: Validate atomic acquisition in futex_lock_pi_atomic()
futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
Там что-то очень криво запатчили, у меня chrome, stardict теперь зависают при запуске. Стопорится наfutex(0xb83e0160, FUTEX_UNLOCK_PI_PRIVATE, 1318900) = -1 EPERM (Operation not permitted)
futex(0xb83d6e74, FUTEX_WAIT_PRIVATE, 1, NULLпосле отката обновления всё ок.
Про BPF http://lwn.net/Articles/599755/
Юзаю с -rc1 на десктопе.
На моём железе не замечал абсолютно никаких косяков, dmesg без матов.
Шустро, стабильно.
То "ждущий" то в том же разделе "спящий"... Не гибернация же. Из S2 и так выход мгновенный, а вот из IRST нет. Это оно, не?
> То "ждущий" то в том же разделе "спящий"... Не гибернация же.Из шушпанда выход может затягиваться, если SSD долго глаза протирает.
> Поддержка новых векторных инструкций AVX-512, которые присутствуют в Xeon Phi и появятся в будущих выпусках процессоров IntelВ Xeon Phi они тоже лишь собираются появиться в 2015-м году (в Knights Landing), тогда как в нынешних Xeon Phi (Knights Corner) вместо них есть 512-битные же аналоги в рамках архитектуры MIC. Между ними есть совместимость на уровне большинства intrinsics (хотя для AVX-512 есть дополнительные, которых для MIC нет), но не на уровне бинарного кода (аналогичные операции с 512-битными векторами кодируются на Knights Corner / MIC и Knights Landing / AVX-512 по-разному). Получается, что нынешние Xeon Phi применимы для отладки и кое-как даже для бенчмарков программ, написаных с использованием подмножества intrinsics общего для MIC и AVX-512, которые после перекомпиляции будут работать и на процессорах с AVX-512. Другой вариант отладки - с использованием эмулятора, Intel SDE. А железо с AVX-512 пока, насколько я знаю, просто так не купить (даже утекших engineering samples пока не видно).
> ... пока не видноLinux уже давно превратился в площадку для рекламы - выпускают драйвера для железа
которого ещё нет, USB3 наверно все помнят. Dec Alpha 21364, IBM Power8, куча SoC, ARM.
Да нормально все, не ссы. Просто нормальные вендоры работают на опережение теперь.
> Для архитектуры x86 теперь не допускается создание 16-разрядных сегментов при работе в 64-разрядном режиме. Изменение внесено так как использование 16-разрядых сегментов может привести к потенциальным проблемам с безопасностью, связанным с утечкой информации из ядра. C небольшой вероятностью данное изменение может нарушить работоспособность некоторых приложений в пространстве пользователя, в частности, перестанут работать 16-разрядные приложения, наличие которых под большим вопросом.То есть эмуляторы игровых приставок теперь придётся запускать в виртуалбоксе, что ли?
Там другие технологии, 16-ти битный x86 код в этих эмуляторах и так не выполняется.Вот что (как мне кажется) может отвалиться, так это dosemu. Во времена 32-х битных архитектур он, насколько я помню, выполнял 16-ти битный код. Но осталось ли это так же (и возможно ли было вообще) в 64-х битной версии, я не в курсе. Но если осталось, то с этим изменением отвалится..
Впрочем, всегда есть dosbox, который более настоящий "эмулятор" и не подвержен этой проблеме.
dosemu давно уже отвалился, по-моему... а dosbox тормозной, как хрен с луком...
Он отваливался, но потом починили.
А вообще глянул, в ченжлоге к 1.4.0 (http://dosemu.sourceforge.net/stable/announce) пишут:- Added a native 64-bit port for x86-64, which, by default, uses CPU emulation
for V86 mode, and runs DPMI code natively.т.е. на x86-64 он уже и так не выполнял 16-ти битного кода. Полностью эмулирует (благо, скорости для эмуляции 80286 о 12 Mhz с мегабайтом ОЗЦ нынче должно хватать везде)), ну а в 32-х битном DPMI режиме выполняет нативно, как и всегда.
Там во времена доса, конечно, была еще куча других извращенных режимов вроде 16-ти битного кода с 24-х битной адресацией aka 80286 Protected Mode, но я сомневаюсь, что dosemu их и так держал.. А V86 и 32-х битных DPMI-режимов должно хватать практически для всего.
ага жутко тормозит на i7 4770k
Ещё Wine, а точнее его эмуляция Windows 3.1, ради которой добавляется правило в sysctl.
> Ещё Wine, а точнее его эмуляция Windows 3.1, ради которой добавляется правило
> в sysctl.есть такое. но право: сколько осталось софтов под 3.1(1), которые сегодня таки ещё есть необходимость запускать? учитывая, что сам 3.1(1) можно запустить под досбоксом.
> есть такое. но право: сколько осталось софтов под 3.1(1),Сетаперы у некоторого софта вполне себе 16-битные бывают. Чтобы уметь посылать юзера в 3.11 винде нафиг. Правда нынче MS сватает 64-битные оси и они сами запускать это 16-битное не умеют, поэтому такое добро более-менее повымерло уже.
> Сетаперы у некоторого софта вполне себе 16-битные бывают.тоже у древности, этот install shield сейчас только в антикварных лавках найти можно. в этом случае поможет какой-нибудь qemu со старой виндой.
> тоже у древности, этот install shield сейчас только в антикварных лавках найти
> можно. в этом случае поможет какой-нибудь qemu со старой виндой.Да мне честно говоря до лампочки на эти виндовые проблемы, у меня виндовых программ уже давно не осталось, никаких и нигде :). Но если кто захочет запустить винтажный сетапер - обломается.
Надеюсь, в этой версии исчезли адовы задержки при обращении к накопителям.
Какие такие задержки, ты о чём ?
При обращении к дискам приложения подвисают на пару-тройку секунд. На 3.12.х такого не было, дальше появилось.
На 3.14 не замечаю.
Какими методами глубокоуважаемый специалист определил задержку обращения? Надеюсь, это были научные методы, а не просто авторитетное мнение?
> При обращении к дискам приложения подвисают на пару-тройку секунд.Может у тебя просто power management дисков заработал и они паркуются если система длительное время ничего не делала? Только это скорее всего вообще не к ядру вопросы.
> На 3.12.х такого не было, дальше появилось.
Ядро не делает с дисками ничего такого, что требовало бы пары секунд. Как максимум, задержка в пару секунд будет если накопитель пару секунд не отвечает на команды. Но это опять же не в компетенции ядра. Само по себе 3.15 (и 3.14, и кто там еще) с дисками работает вполне шустренько, без задержек. А величина 2-3 секунды намекает на время на раскрутку шпинделя. Остальные времена обычно порядка миллисекунд.
чел может не знает, что у него там непомуки всякие с аконадями включены, или шняга какая на моно болтается без присмотра, мало ли что там wait i/o может задирать.
Интересная версия, но звуков раскрутки/остановки дисков я не слышу.Вообще, я немного неверно сформулировал проблему, задержки не только при обращении к накопителям. Почти все приложения стали дольше открываться. При закрытии некоторых приложений (KSysGuard самый стабильный пример) они не закрываются сразу, а замирают на секунду-две. su в Konsole выполняется безбожно медленно - между вводом пароля и приглашением рута проходит секунд 10 (!). Словом, ад какой-то.
На 3.15 то же самое.
> Интересная версия, но звуков раскрутки/остановки дисков я не слышу.Ок, тогда отпадает. Это просто единственный вариант который я вспомнил при котором программу может на 3-4 секунды заклинить в каком-нибудь файловом системном вызове, пока механический диск разгонится (3.5" диски разгоняются довольно долго). Еще при сильной нагрузке на диск некоторые файловые вызовы могут занять прилично времени. Ну если у вас ksysguard есть - он умеет показывать нагрузку на диски? Если да - им и посмотреть насколько диски вообще озадачены (IOPSы и скорости чтения/записи).
> Вообще, я немного неверно сформулировал проблему, задержки не только при обращении к
> накопителям. Почти все приложения стали дольше открываться.Ради интереса запустил на холодную офис. С SSD правда. Электронные таблицы (Calc) из LibreOffice стартуют за ~1.5 секунды (довольно резво для такой программы). Закрывается моментально. Geany - вылетает на экран моментально, как и закрывается, etc. Ядро 3.15 релизное. Вроде недурно.
> При закрытии некоторых приложений (KSysGuard самый стабильный пример)
> они не закрываются сразу, а замирают на секунду-две.А что ksysguard вообще с диском может делать? И вообще, что вы как маленькие? Посмотрите не озадачены ли диски под завязку. Если не озадачены и нифига не понятно - возьмите strace или новомодный sysdig и *посмотрите* что именно программа делала все это время. Отловив вызов в котором отвисало 2 секунды.
> su в Konsole выполняется безбожно медленно - между вводом пароля
> и приглашением рута проходит секунд 10 (!). Словом, ад какой-то.И есть уверенность что все 10 секунд система отвисает именно в системных вызовах, в режиме ядра, так что предъявы - именно ядру? А благородный дон это трассировал?
Просто элементарная логика подсказывает что за такие баги юзерье Торвальдса и причастных давно заклевало бы в багтрекере, будь это страшный баг в ядре. Пару релизов он бы не прожил - юзвери съели бы разработикам мозг. Не говоря уж о том что самих разработчиков это задолбало бы первым делом :).
> На 3.15 то же самое.
А кроме ядра ничего не менялось? И еще... su, 10 секунд... я что-то такое видел когда были проблемы с резольвом имени машины. При этом случается тупняк до некоего таймаута, потом логин все-таки происходит. Но к ядру это никак не относилось. Возможно в системе поменялось что-то еще и ядро тут никак не относится к делу? Хотя проверить просто: ничего не меняем, кроме установки старого ядра. Грузимся. Смотрим. Если проблема отпала - очень интересно, да.
Виновник найден, это не совсем ядро, это Btrfs. В ядрах 3.13 и дальше что-то намутили, теперь если снапшотов больше десятка, начинаются такие вот лаги. Удалил старые снапшоты - всё нормализовалось. Буду ждать ядро 3.16
> теперь если снапшотов больше десятка, начинаются такие вот лаги.
> Удалил старые снапшоты - всё нормализовалось. Буду ждать ядро 3.16Вообще, большая пачка снапшотов вполне может вызвать определенные проблемы. Ибо метаданных из которых строится текущий вид будет довольно много - некое время на понимание как выглядит файл именно сейчас - уйдет. И будет туева хуча фрагментов, которые как шалтая-болтая придется по всему диску собирать. Это для вращающихся дисков не очень хорошая затея. Но все-равно как-то слишком злобно целую секунду тупить.
Попробуй сделать 10 снапшотов подряд и если оно и при так тормозит - заведи им баг :). Ибо нефиг, пусть оптимизируют, если это от самого факта 10 снапшотов. Но если это было 10 далеко отстоящих друг от друга состояний - ну ой, такое возможно в большинстве CoW-механик. Стоит понимать что когда ты в первый раз пометил снапшот, все изменения относительно "базовой" версии будут писаться как выноски вбок, и из этого на ходу строится новое состояние файла. Когда делается еще один снапшот - измененные блоки включаются в то новое зафиксированное состояние. И тут стоит понимать что если снапшот сделан год назад и с тех пор была куча изменений - вся эта куча изменений относительно того что было год назад - будет занимать место на диске и может понизить скорость работы. Такие же проблемы характерны для, например, VM с кучей снапшотов. Поэтому древние снапшоты неплохо иногда удалять и делать новые. Ну или не отращивать кучу изменений.
p.s. и да, сорри за наезды на квалификацию. Задетектировать такую ситуацию не зная о подобном свойстве CoW-based механик - не самая простая задача.
> Такие же проблемы характерны для, например, VM с кучей снапшотов.(глядя на два десятка снапшотов в виртуалящике, некоторые из которых полуторалетней давности) кто-то опять трындит.
Зачем ошмётки шланга в ядре ?
клёвая штука. уже лет 15 использую, всем рекомендую.
> клёвая штука. уже лет 15 использую, всем рекомендую.Ты 15 лет используешь 3.15? Так вот кто угнал машину времени с ЛОРа?!
Самый большой список коммитов за историю проекта? У АНБ появился хороший шанс после провала с OpenSSL.
>В блочном устройстве zRAM, применяемом для хранения раздела подкачки в ОЗУ в сжатом видеКто-нибудь мне объясните, на кой черт оно вообще надо?
Если памяти много, своп не нужен. Ежели мало - тем более, нафига забивать его образом свопа, да еще и сжатым? Как правило, там где памяти мало, там и проц никакой, на кой черт тратить его ресурсы на сжатие/распаковку?
>>В блочном устройстве zRAM, применяемом для хранения раздела подкачки в ОЗУ в сжатом виде
> Кто-нибудь мне объясните, на кой черт оно вообще надо?
> Если памяти много, своп не нужен. Ежели мало - тем более, нафига
> забивать его образом свопа, да еще и сжатым? Как правило, там
> где памяти мало, там и проц никакой, на кой черт тратить
> его ресурсы на сжатие/распаковку?бывают устройства, где нет накопителя, но есть много ОЗУ. а бывают програмы, которые кричат - дай мне свап!
>бывают устройства, где нет накопителя, но есть много ОЗУ.Примерчик можно?
>бывают програмы, которые кричат - дай мне свап!
Говори уж прямо - проприетарщина, собранная криворукими обезьянами. Я как-то не упомню, вот вообще, хотя бы одну FOSS-софтину, которая с ножом у горла требовала бы наличия свопа.
>>бывают устройства, где нет накопителя, но есть много ОЗУ.
> Примерчик можно?
>>бывают програмы, которые кричат - дай мне свап!
> Говори уж прямо - проприетарщина, собранная криворукими обезьянами. Я как-то не упомню,
> вот вообще, хотя бы одну FOSS-софтину, которая с ножом у горла
> требовала бы наличия свопа.ну как бы да, но разве ядро Линукс против проприетарщины? не нравится - выпили данное новшество...
> Кто-нибудь мне объясните, на кой черт оно вообще надо?Мы использовали на тонких клиентах, где мало CPU, мало RAM и нельзя полагаться на наличие локального диска. Благодаря тому, что эти ещё тогда патчи были включены в школьный терминальный сервер, клиенты с 32..64M работали вполне комфортно (разумеется, сетевой своп всё равно был нужен, но когда он используется как zswap -- и тормозит меньше).
Как он "тормозит меньше", если "мало CPU"? Или юзается проц терминального сервера?
> Как он "тормозит меньше", если "мало CPU"?Алгоритмы типа LZO и LZ4 достаточно быстры и работают на скорости являющейся существенным процентом от memcpy(). Поэтому иногда бывает так что лучше пусть проц попашет компрессуя страницы, сэкономив время на I/O, нежели чем если проц будет в разы больше курить бамбук ожидая завершения I/O операций.
иногда/изредка на своеобразных конфигурациях, ассимеричных/несбалансированных.
> иногда/изредка на своеобразных конфигурациях, ассимеричных/несбалансированных.Для любого механического диска и сколь-нибудь современного проца - скорость сжатия и распаковки зело перевешивает скорость записи на диск. За исключением разве что SSD, который свопом протирать как-то жалко. Ибо дорогой, зараза. А есть еще всякая эмбедовка, где свопа может или не быть совсем (как например в роутерах всяких) или же он тормозной и опять же протирает флешатину (как в всяких смартфонах).
>> иногда/изредка на своеобразных конфигурациях, ассимеричных/несбалансированных.
> Для любого механического диска и сколь-нибудь современного проца - скорость сжатия и
> распаковки зело перевешивает скорость записи на диск. За исключением разве что
> SSD, который свопом протирать как-то жалко. Ибо дорогой, зараза. А есть
> еще всякая эмбедовка, где свопа может или не быть совсем (как
> например в роутерах всяких) или же он тормозной и опять же
> протирает флешатину (как в всяких смартфонах).но так или иначе - это тупик и костыль.
и облегчение жизни, криворуким программистам и старадающим от их профнепригодности, потребителям/заказчикам - не есть доброе дело, в долгосрочной перспективе.
это как алкоголику/наркоману денег дать - вроде и добрый жест, но убьет его. и отрасль.
> но так или иначе - это тупик и костыль.А вы кто такое чтобы за всех решать?
> и облегчение жизни, криворуким программистам
При чем тут программисты? Это скорее к железу больше вопросы что I/O столь неспешное что проц + оператива сильно быстрее, настолько что сжатие дает прирост за счет экономии на I/O операциях.
> и старадающим от их профнепригодности,
Судя по заявам, профнепригодностью тут страдаете ... вы.
> это как алкоголику/наркоману денег дать - вроде и добрый жест, но убьет его. и отрасль.
Да вот как-то так вышло что систем с бесконечным объемом оперативы еще не производят.
> Да вот как-то так вышло что систем с бесконечным объемом оперативы еще
> не производят.Он о том, что для hello world или пишмашинки бесконечный вовсе и не требуется, насколько понимаю.
> Он о том, что для hello world или пишмашинки бесконечный вовсе и
> не требуется, насколько понимаю.Ну если расширить эту логику - проц в тетрисе вообще прекрасно живет с mask ROM и парой сотен байтов оперативки прямо на кристалле. И никакого свопа не требуется. И вообще внешних накопителей.
>>В блочном устройстве zRAM, применяемом для хранения раздела подкачки в ОЗУ в сжатом виде
> Кто-нибудь мне объясните, на кой черт оно вообще надо?Это надо затем, что сжать страницы и поместить их в RAM - как правило здорово быстрее чем выдавливать их на диск. Получается "сжатая оперативка". И да, скорость работы LZ4 измеряется в гигабайтах в секунду на топовых х86 и сотнями мегов в секунду на каком-нибудь ARM. Так что вполне можно поиметь профит на сокращении I/O, который в случае механических дисков тормозной, а в мелких девайсах - дорогой по CPU и/или протирает флеш-память.
> Как правило, там где памяти мало, там и проц никакойИ? У тебя всегда 100% загрузка проца, "чтоб не жалко"?
> на системах с дисковыми контроллерами SATA.
> время вывода из ждущего режима компьютера на базе Intel Core i7 3960X уменьшилось с 11.6 до 1.1 секунд (в 10.5 раз)Интересно. У меня не SATA, а PATA (UDMA/100), и на ядре 3.14.5 пробуждается за 5—6 секунд с Pentium 4 524 и Western Digital WD800JB-00JJC0.
У меня SATA, 2-ухядерный Celeron 1,5 GHz и лэптоп пробуждается примерно за 1,5 - 2 секунды с ядром 3.11
Скорость пробуждения зависит от количества дисков. Чем больше дисков, тем дольше надо ждать. По крайней мере, на ядрах до 3.15.
>Добавлен драйвер, позволяющий представить Flash-накопитель в виде блочного устройства (пока только в режиме только для чтения), что позволяет использовать любую файловую систему поверх raw Flash-устройства;Вот это не влазит в голову.
А до этого флэшки были неблочными устройствами? На флэшке(например sdc) нельзя было создать ФС какую тебе угодно(хоть нтфс)? Может какие-то специфические ОС типа кластерные и т.п. не хотят не ставятся на флэшку, но это из данной фразы как-то прозрачно не вытекает. Кстати читал, как-то софтрэйд собирали на флэшках...
>>Добавлен драйвер, позволяющий представить Flash-накопитель в виде блочного устройства
> Вот это не влазит в голову. А до этого флэшки были неблочными устройствами?Видимо, речь про какой NAND, а не про готовый USB Flash.
>>>Добавлен драйвер, позволяющий представить Flash-накопитель в виде блочного устройства
>> Вот это не влазит в голову. А до этого флэшки были неблочными устройствами?
> Видимо, речь про какой NAND, а не про готовый USB Flash.а...
тогда наверно уместнее написать не флэш-накопитель, а флэш-чип, накопитель уже как бы подразумевает под собой бл.устройство...
Написано же - raw flash. А флешка - это контроллер, за которым 1 или несколько чипов флеша. Raw флеш - это когда контроллера нет, а чип флеша напрямую интерфейснут к системному процессору.
А если конкретно, речь про UBI - раньше поверх него только UBIFS работал, а теперь оно может в виде блочного девайса чип представлять => можно любую ФС поверх него гонять будет.Вопрос только в том, будет ли при этом wear leveling... (если будет - имхо, это круто!)
> Вопрос только в том, будет ли при этом wear leveling... (если будет
> - имхо, это круто!)Короткий ответ: да.
Второй короткий ответ: _будет. :D
Длинный: Ну, если "read-only" в
* The UBI flash translation layer has gained a driver that can make a flash device appear to be a (read-only, for now) block device. That enables the use of any filesystem on top of a raw flash device.
не смущает, "for now" же, то http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01850.html можно https://lkml.org/lkml/2014/4/3/311 об этом http://lwn.net/Articles/459957/ и http://lwn.net/Articles/525957/ поговорить http://www.gossamer-threads.com/lists/linux/kernel/1635410
А как вообще что-то записать на UBI, минуя UBIFS, если поддержки записи нет? :-)))
> А как вообще что-то записать на UBI, минуя UBIFS,Не то чтобы на UBI, но читать про MTD-девайсы. Таки /dev/mtd* позволяют читать, а иногда и записать флеху в виде "как есть". Правда "как есть" - тоже понятие растяжимое. У NAND например есть "out of band" информация - данные алгоритма ECC. И есть два варианта - можно получить назад только свои данные, а можно полный блок, вместе с ECC. А еще бывают битые блоки (и сведения о таковых). Их по идее читать и писать не следует. Поэтому идея совсем напрямую работать с флешом вообще совсем без прослоек - достаточно чревата и только для тех кто готов столкнуться с подобными странностями + тем фактом что флеш пишется по очень странным принципам.
>> А как вообще что-то записать на UBI, минуя UBIFS,
> Не то чтобы на UBI, но читать про MTD-девайсыubiblock б. ubiblk по ссылкам же выше?! по ссылкам!! кто здесь!!??
> ubiblock б. ubiblk по ссылкам же выше?!Ага, удачи в записи чего либо. При том что он readonly :).
>> ubiblock б. ubiblk по ссылкам же выше?!
> Ага, удачи в записи чего либо. При том что он readonly :).А теперь сходи по _всем_ ссылкам выше. :S Анализируй это!
Основное отличие от классических POSIX-блокировок заключается во владельце блокировки: классической POSIX-блокировкой владеет процесс, а приватная POSIX-блокировка принадлежит открытому файлу
А как файловые менеджеры на это смотрят? Ничего не отваливается?
очень понравилось это ядро: https://www.dropbox.com/s/xyfcnidv6zog0a2/20140609_092120.mp4
У меня такое было когда мост отпаялся от мат. платы. Часть шариков пайки лопнула и при определенной температуре+фазе луны+загрузки видеокарты появлялось такое и до остывания компа продолжалось.
теперь я понял, что произошло со старым ноутом. Но этот - новый, здесь дело не в аппаратных проблемах.
Это интеловый интеграт? Там у них были какие-то баги такого плана.
A+A новый ноут. Старый просто A. Интела не было.
> A+A новый ноут.Что есть A+A? Не удается декодировать сие в сколь-нибудь осмысленные чипы или ядра таковых.
> Поддержка процессоров Loongson 3Китайцы конечно молодцы, но когда же Эльбрус объявится?
>> Поддержка процессоров Loongson 3
> Китайцы конечно молодцы, но когда же Эльбрус объявится?когда узлов с ним - будет сопоставимое с китайскими MIPS-ами, количество.
или количество компаний, коммерчески использующих.
или пока эльбрус, внезапно - не начнет Сам коммитить в паблик. и если, что врятли.