Сравнение мужей: Systemd vs Upstart (свежая заметка от А.Федорчука)

обещают поддержку этого:

Windows 7, Windows Vista, Windows XP x64, Windows XP, Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 x64, Windows 2003 Server, Windows 2003 R2 Server, Red Hat Enterprise Server 5, SuSE Linux Enterprise Server 11, FreeBSD 8, SCO UnixWare 7, SCO OpenServer 6.0, Sun Solaris 10, VMware ESXi 5.0, VMware ESXi 4, VMware ESX

поддержка остального НЕ гарантируется. Почему-то я уверен, что у тебя ОС не из этого списка. Я угадал? Ну вот и думай в следующий раз перед покупкой. Колёса для БелАза конечно круто, но в запорожец не лезут. ИЧСХ, это не баг, а фича.

Почему-то я уверен, что у тебя ОС не из этого списка. Я угадал?

Нет. SLES 11.

тогда бери. Очевидно, что это гарантийный случай, если оно не заработает, и ты принесёшь обратно.

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

Ах, да. Что значит: «тогда бери»? У нас таких уже около пары десятков. Под сабжем с высокой VM IO вышеописанные проблемы, под шиндош - нету.

У нас таких уже около пары десятков. Под сабжем с высокой VM IO вышеописанные проблемы, под шиндош - нету.

какая-то несовместимость какой-то железки с какой-то ОС. Пишите багрепорт. Под _общий_ случай это явно НЕ подходит, ибо два девайса сразу отлично работают в Linux. Ну атдельные проблемы бывают везде, в венде — тоже бывают. У них там вообще BSOD на рабочем железе — статистика.

Т.е. аналогичная хрень при обновлении системы на десктопе на совершенно другом железе - это «несовместимость какой-то железки с какой-то ОС», но никак не вина kernel? Может, ты еще дашь ссылку на коммит, которым был 12309 исправлен? А то модератор багзиллы на этом вопросе слился.

Больше диалектизмов :) Твоя речь будет всем понятна :)

Т.е. аналогичная хрень при обновлении системы на десктопе на совершенно другом железе - это «несовместимость какой-то железки с какой-то ОС»

Ты сиськи видел? А знаешь зачем они? Детёнышей кормить. ИЧСХ, миллионы женщин по всей планете НЕ кормят грудью. Не могут. Из этого следует, что сиськи не нужны?

Извини, но мне просто непонятна твоя логика.

из утверждения «Сам ползи в корчах на помойку. При том, что лайнакс не может в параллельный I/O на разных носителях (см 12309), иметь два и более винтов, кроме как за весьма дорогим кэш-контроллером с батарейкой, да и то не спасет, - это «я у мамы дурачок»», прямо следует решение партии и правительства отрезать всем женщинам сиськи, ибо они всё равно не нужны, разве что при наличие очень дорогих докторов. Но молочная смесь будет дешевле даже в этом случае.

Может, ты еще дашь ссылку на коммит, которым был 12309 исправлен?

Status: CLOSED CODE_FIX

Modified: 2013-04-05 07:00

https://bugzilla.kernel.org/show_bug.cgi?id=12309

А то модератор багзиллы на этом вопросе слился.

это ты про что?

Он неправильно тестировал. Надо было openSUSE с upstart и openSUSE с systemd. В одном из предыдущих релизов openSUSE обе системы инициализации были доступны.

Ищу тех кто может помочь автоматизировать сборку SRPM-ок в openSUSE 12.3 без systemd. Напишите или помогите написать скрипт для сноса из системы systemd

Status: CLOSED CODE_FIX

Это не коммит. Это «bugzilla bug status». На коммит ссылку дай. Модератор багзиллы, который сослался на CODE_FIX в этом вопросе слился.

Ты сиськи видел? А знаешь зачем они? Детёнышей кормить. ИЧСХ, миллионы женщин по всей планете НЕ кормят грудью. Не могут. Из этого следует, что сиськи не нужны?

Раз уж ударяться в биологию: не сиськи не нужны, а чисто эволюционно детей у этих миллионов женщин не должно никогда быть. Либо наоборот, чисто эволюционно кормление грудью - атавизм, и тогда да, «сиськи не нужны». Но покажет это только время, гораздо более длительный его отрезок, нежели пара десятков лет на устранение возврата в эпоху PIO и жутких фризов приложений, обсуждаемых в 12309. Причем, про пару десятков лет я еще не уверен.

Это «bugzilla bug status».

этого мало, что-бы считать статус бага закрытым?

На коммит ссылку дай.

12309 в итоге расползся на Over9000 багов совершенно разной природы.

Но покажет это только время, гораздо более длительный его отрезок, нежели пара десятков лет на устранение возврата в эпоху PIO и жутких фризов приложений, обсуждаемых в 12309.

сейчас 12309 наблюдается только на каком-то конкретном железе в каких-то конкретных условиях. Обычно никаких фризов не наблюдается (с ванильным ядром, и с не слишком специфичным железом, и не на каких-то безумных юзкейсах). Да, глюки на каких-то конкретных железках были, есть и будут. Ну и что? Это в любой ОС есть.

сравнение ужей

этого мало, что-бы считать статус бага закрытым?

Да, поскольку после закрытия бага жалобы пользователей на проблемы, описанные в багрепорте, продолжались. К тому же не указано, где и когда (а, главное, как) были произведены исправления в коде. Возможно, кто-нибудь смог бы предложить решение получше.

12309 в итоге расползся на Over9000 багов совершенно разной природы.

Что не отменило проблему, описанную в багрепорте: фризы, например, курсора мыши при `huge VM IO load`. У меня это на всех писюках и серверах в течение последних 5 лет воспроизводится 100%, например, при обновлении пакета kernel-source. На серверах, конечно, индикатор не курсор мыши, а, например, вход по ssh.

сейчас 12309 наблюдается только на каком-то конкретном железе в каких-то конкретных условиях

И конкретизируются они так:

- практически любое железо

- практически любые условия, при которых соблюдается использование linux kernel

Ну, и вот еще что: может, ты мне объяснишь природу 100% как минимум на одном из ядер CPU системы в момент VM IO? Оно еще называется iowait load. Модераторы (или разработчики, на их никнеймах не написано) объяснить толком не смогли.

А.Федорчука

Я давно читаю его статейки...Вот мне вдруг спросилось, на LOR Федорчук присутствует? Кто знает?

Точно присутствовал на Юниксфоруме.

На ЛОРе федорчуков не бывает.

Да, поскольку после закрытия бага жалобы пользователей на проблемы, описанные в багрепорте, продолжались. К тому же не указано, где и когда (а, главное, как) были произведены исправления в коде. Возможно, кто-нибудь смог бы предложить решение получше.

там Over9000 багов, и соответственно Over9000 решений. Предлагай, только сначала свой баг найди.

Что не отменило проблему, описанную в багрепорте: фризы, например, курсора мыши при `huge VM IO load`. У меня это на всех писюках и серверах в течение последних 5 лет воспроизводится 100%, например, при обновлении пакета kernel-source. На серверах, конечно, индикатор не курсор мыши, а, например, вход по ssh.

для этого обязательно надо два sdX-девайса? А на одном девайсе воспроизвести можно? Если да, то как?

практически любое железо

почему же я не наблюдаю?

Ну, и вот еще что: может, ты мне объяснишь природу 100% как минимум на одном из ядер CPU системы в момент VM IO? Оно еще называется iowait load. Модераторы (или разработчики, на их никнеймах не написано) объяснить толком не смогли.

могу, как только его увижу, твою загрузку на 146%. Сложно объяснить то, чего нет.

А на одном девайсе воспроизвести можно? Если да, то как?

Можно на одном и более. Как - в 12309 куча рецептов по генерации excessive VM IO.

там Over9000 багов, и соответственно Over9000 решений. Предлагай, только сначала свой баг найди.

Нашел. Мой баг - первый пост в 12309.

могу, как только его увижу, твою загрузку на 146%. Сложно объяснить то, чего нет.

Сгеренируй по рецептам нагрузку на дисковую подсистему и помониторь wa в iostat, например. Увидишь, как лихо idle корректируется на значение в показателях iowait.

Сгеренируй по рецептам нагрузку на дисковую подсистему и помониторь wa в iostat, например. Увидишь, как лихо idle корректируется на значение в показателях iowait.

оно воспроизводится лишь при острой нехватке памяти, на 512..768и Мб оперативки, когда всё забито. В таком юзкейсе вся система и так на гране фризов, из-за жестокого свопинга. И да, ещё Кнут математически доказал, что _любая_ система просто обязана тупить и глючить в ситуации, когда память почти кончилась. Время, которое требуется системе для поиска последних свободных крошек памяти огромно и неоправданно, но что в этом странного? Да, венду ты до такого вряд-ли доведёшь, но лишь по той простой причине, что оно начнёт ТОРМОЗИТЬ намного раньше. Медленно и верно. А вот в Linux тормоза наступают ВНЕЗАПНО. Разве это плохо? Ведь диапазон заполнения памяти при _нормальной_ работе, намного шире. Т.е. с X Mb RAM в Linux ты можешь работать без проблем, а в венде уже — нет. С X+1 Mb и там и там работать нельзя, ну и что?

Пойми простую вещь: для всякого копирования просто необходима память, которая используются как буфер. Если у тебя памяти нет, то система _вынуждена_ мучиться в поисках памяти под этот буфер, и найдя несколько свободных байт просто вынуждена копировать по несколько этих байт. А вот современные девайсы так не умеют, а умеют только мегабайтами. Вот и получается, что сначала система читает мегабайты с источника, и ОДНОВРЕМЕННО их распихивает по маленьким дырочкам в памяти, потом она их заталкивает в цель, собирая из этих многочисленных дырок. Естественно это долго, и сильно грузит CPU. Естественно, в таком режиме не работает DMA, что удивительного?

Самое забавное, что эту самую острую нехватку памяти легко и непринужденно генерирует само ядро независимо от суммарного объема модулей в системе. Называется «фича», через которую течет память - VM Cache

$ free
             total       used       free     shared    buffers     cached
Mem:      49498684   47605808    1892876          0    4244976   36015904
-/+ buffers/cache:    7344928   42153756
Swap:      8385920      62332    8323588

$ iostat
Linux 2.6.32.54-0.3-default (mail)      07.05.2013      _x86_64_

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3,56    0,02    0,29    2,36    0,00   93,77

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda              22,17       254,21       521,29  967460078 1983896864
sdb              35,51      9974,32      6122,84 37960045312 23302160248
dm-0             43,64        75,03       398,86  285563002 1517967736

Смотри, как ништячно: из ~48 гиг оперативы ~36 в дисковом кэше и потому аж часть данных (62 метра) ухнуло в своп. Понадобится их использовать - будем дико тормозить. Не спорю, при обращении к закэшированным файлам на дисковой подсистеме оно тупо отдаст из оперативы. Мы счастливы от того, что письмо из IMAP-папки SPAM будет через 30 дней отдано на растерзание ассассину практически мгновенно.

Отдельно обрати внимание на %iowait. Оно не нулевое, хотя и низкое, что говорит о том, что в данном конкретном случае кэширование все же эффективное.

А вот другой сервак:

$ free
             total       used       free     shared    buffers     cached
Mem:       7997968    7350860     647108          0      14052    6943176
-/+ buffers/cache:     393632    7604336
Swap:      9181140     233772    8947368

$ iostat
Linux 3.0.42-0.7-default (sql)  07.05.2013      _x86_64_

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          15,67    0,01    0,88   13,73    0,00   69,72

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdc               0,59         0,51       427,25    1933686 1626192280
sda               3,10        81,21         6,02  309118739   22902617
sdb              67,50      8659,90      1024,14 32961149184 3898077264

А вот современные девайсы так не умеют, а умеют только мегабайтами

Все дисковые накопители, ЕМНИП, обязаны отдавать минимальный блок равный сектору (512 байт), которыми, собственно и оперируют таблицы разделов и т.д. А ты, наверное, перепутал с дисковым кэшем, он совсем другое и для другого.

Не спорю, при обращении к закэшированным файлам на дисковой подсистеме оно тупо отдаст из оперативы. Мы счастливы от того, что письмо из IMAP-папки SPAM будет через 30 дней отдано на растерзание ассассину практически мгновенно.

а там конечно есть более приоритетные задачи? И у тебя конечно есть способ решения надуманной тобой же проблемы?

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

ну и что ты хотел увидеть?

и я в который раз уже вспоминаю времена PIO (кстати, забавна реакция разработчика ядра на упоминание PIO в контексте 12309 - мол, у тебя в dmesg что написано? DMA? значит, у тебя DMA!). Была бы там другая задача, скажем, чисто вычислительная, внезапный сислог делал бы нам убыток по вычислительной мощности не сопоставимый с вычислительной задачей «записать в журнал строку».

блжад. Пойми простую истину: DMA ХУЖЕ PIO, если данных мало. DMA долго запрягает, и быстро едет. Если нужно часто запрягать и/или далеко ехать не нужно, то DMA — плохой вариант. Но вот выбора таки и нет, контроллер определяется как DMA, откуда и тормоза, ибо памяти мало, и писать данные некуда, вот и имеем тормоза и iowait. Это как раз то самое время запрягания, которое тебе _необходимо_ затратить, дабы прочитать свои 512 байт.

Все дисковые накопители, ЕМНИП, обязаны отдавать минимальный блок равный сектору (512 байт), которыми, собственно и оперируют таблицы разделов и т.д. А ты, наверное, перепутал с дисковым кэшем, он совсем другое и для другого.

я ничего не путал. Накопитель обязан, он и отдаёт. Но никто тебе НЕ гарантировал скорость на 512и байтах. Её и нет. И на HDD нет, да и на SSD тем более(ЧСХ) нет. Эти носители _принципиально_ так не умеют. Вот 300Мб за секунду умеют, а вот 512 байт они будут читать далеко НЕ в 600 000 раз быстрее. И хорошо, если в 600 раз(на SSD), а не в 60(HDD).

а там конечно есть более приоритетные задачи?

mailboxd. Он на том серваке наиболее приоритетный, следом slapd, postfix и amavisd. Но никак не дисковый кэш.

И у тебя конечно есть способ решения надуманной тобой же проблемы?

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

Но вот выбора таки и нет, контроллер определяется как DMA

Да ладно, я вот до сих пор помню, даже в древней, как экскременты мамонта шин2000 был переключатель в драйвере контроллера: PIO/DMA. А в прогрессивном линуксе разработчиков Мигелюшка, что ли покусал, чтоб не вздумали давать пользователю возможность выбрать?

Накопитель обязан, он и отдаёт

А вот современные девайсы так не умеют, а умеют только мегабайтами

Ну да, ну да... Так не умеют, или обязаны и отдают?

Но никто тебе НЕ гарантировал скорость на 512и байтах

Ты совсем запутался в своих фантазиях. Я не утверждал, что 5Mops по 512 байт должны выполняться на скорости 1op длиной даже 2Мбайт. Я прекрасно понимаю, что удельная доля Command Protocol Payload больше там, где больше этих самых команд передается в пределах одного и того же объема информации. Я говорил лишь о том, что excessive VM IO грузит проц по показателю «ожидаю» (что есть логический бред) и при этом умудряется даже влиять на операции, не требующие вообще никакого VM IO (как, например, пресловутый курсор мыши).

Ну да, ну да... Так не умеют, или обязаны и отдают?

обязаны, отдают, но мееедлееенннооооооо…

В этом-то вся и проблема.

Ты совсем запутался в своих фантазиях. Я не утверждал, что 5Mops по 512 байт должны выполняться на скорости 1op длиной даже 2Мбайт. Я прекрасно понимаю, что удельная доля Command Protocol Payload больше там, где больше этих самых команд передается в пределах одного и того же объема информации.

я ничуть не путаюсь. Если забирать с носителя(любого) по 512 байт рандомно, то его характеристики будут ХУЖЕ, чем даже в режиме PIO. И если ты наконец включишь голову, ты это поймёшь.

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

Причём я хочу особо отметить, что это НЕ БАГ, а фича. Венду до этого момента домучить практически невозможно, ибо она начнёт тупить гораздо раньше. Впрочем, в моих опытах я таки этого добился, путём того, что поставил венду(XP) в RAM в виртуалке, и выделив ей немного(192) памяти. Она тоже начала жутко тупить при попытке скопировать с HDD(ага, уже НЕ из памяти), при этом таскменеджер показывал 0% CPU, хотя процесс VB жрал все 100%. Также данный эффект наблюдался и без виртуалки, на голом железе: температура камня была большая, порядка 80°, при этом таскменеджер показывал 0%, и всё тупило, в т.ч. и курсор мыши. Откуда я сделал вывод, что 12309 и в венде существует, просто таскменеджер НЕ показывает ЭТУ загрузку. Но кому от того легче?

Выводы, которые я сделал из своих опытов очевидны: Кнут таки прав. Если его матан говорит, что система _должна_ тупить, то она _будет_ тупить. И чем лучше система, тем лучше она работает ДО этого момента, теория такая штука, которая неумолима и на неё не влияет ни что.

Я говорил лишь о том, что excessive VM IO грузит проц по показателю «ожидаю» (что есть логический бред) и при этом умудряется даже влиять на операции, не требующие вообще никакого VM IO (как, например, пресловутый курсор мыши).

по поводу ожидания: оно разным бывает. Можно выполнить HLT, и так обычно и делают, ибо это не мешает другим процессам, а если их нет или они все сами в HLT, то это остужает камень. Это хорошо. Но при работе с DMA на это тупо НЕТ ВРЕМЕНИ. Потому приходится гонять бесконечный цикл, проверяя, не растормозился-ли этот контроллер, и когда он наконец уяснит свою ТЗ. Потом контроллер работает отдельно, а процессор — отдельно. Проблема в том, что если данных мало, то основное время занимает эта самая инициализация, а вовсе не сама передача. Этого очень просто добиться путём тотального засирания физической памяти, так, что-бы в ней было свободного места только в виде кучи маленьких дырок. В этом случае, для КАЖДОЙ дырки нам придётся опять инициализировать контроллер, и душить этим CPU. Ну что собственно мы и наблюдаем. Это совсем не новое явление, и меня удивляет лишь то, что вы это как-то по новому видите. На самом деле, иначе и быть не может.

как, например, пресловутый курсор мыши

а вот пресловутый курсор тормозит по той причине, что шина у нас ОДНА, даже если есть с десяток ядер. И если её постоянно долбить с вопросом к контроллеру DMA, то мышиным сигналам попросту не пробиться (ибо их приоритет ниже плинтуса). В нормальном режиме запросы к DMA составляют сотые доли процента, и потому незаметны, но если их 146%, то конечно мышка начинает обмораживаться. В этом я также не вижу ничего странного, и иначе и быть не может. Решение очевидно — НЕ долбить контроллер DMA постоянными запросами. А читать БОЛЬШИЕ куски данных за ОДИН раз. Очевидно, что это возможно тогда, и только тогда, когда в памяти есть соответствующие дыры, что-бы эти куски принять с носителя. В Linux система находит эти дыры в файловом кеше, туда и пишет.

Ну вот я привел тебе листинги. Возьми второй. Я ни в коем случае не утверждаю, что идут чтение-запись линейно. Но обрати внимание: в кэшах более 6 гиг, причем, это «файловый кэш», т.е. тот, на который в любой момент времени можно забить вообще, высвободить всю память чохом и отдать ее, к примеру, жабке, которая просрет ее гораздо эффективнее. Ибо абсолютная копия всего этого кэша есть на энергонезависимом носителе. Тем не менее, 1 ядро из 4х 5 тактов из 10 тратит на вот это самое «ожидание» при том, что в секунду выполняется каких-то 70 транзакций?

Но при работе с DMA на это тупо НЕТ ВРЕМЕНИ. Потому приходится гонять бесконечный цикл, проверяя, не растормозился-ли этот контроллер, и когда он наконец уяснит свою ТЗ

Вот, помнится, с сетевухами в свое время, решая, как я понимаю, аналогичную проблему, придумали polling technique. Разве с винтами не вариант? И проц отдыхает, и винт, когда нашел, тогда и прислал данные, тем более, если не спросили вовремя и половина запрошенного вылилась мимо переполненного буфера, можно переспросить (пусть кэш винта работает, не зря ж его там уже сотнями метров местами можно насчитать), в отличие от сетевух, особенно ethernet, особенно, если там вообще не IP и тем более не TCP.

Я давно читаю его статейки...Вот мне вдруг спросилось, на LOR Федорчук присутствует? Кто знает?

http://juick.com/1935471#7

Ну вот я привел тебе листинги. Возьми второй. Я ни в коем случае не утверждаю, что идут чтение-запись линейно. Но обрати внимание: в кэшах более 6 гиг, причем, это «файловый кэш», т.е. тот, на который в любой момент времени можно забить вообще, высвободить всю память чохом и отдать ее, к примеру, жабке, которая просрет ее гораздо эффективнее. Ибо абсолютная копия всего этого кэша есть на энергонезависимом носителе. Тем не менее, 1 ядро из 4х 5 тактов из 10 тратит на вот это самое «ожидание» при том, что в секунду выполняется каких-то 70 транзакций?

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

Вот, помнится, с сетевухами в свое время, решая, как я понимаю, аналогичную проблему, придумали polling technique. Разве с винтами не вариант? И проц отдыхает, и винт, когда нашел, тогда и прислал данные, тем более, если не спросили вовремя и половина запрошенного вылилась мимо переполненного буфера, можно переспросить (пусть кэш винта работает, не зря ж его там уже сотнями метров местами можно насчитать), в отличие от сетевух, особенно ethernet, особенно, если там вообще не IP и тем более не TCP.

плотность потока данных от винта НАМНОГО выше, чем от сетевухи. Попросту времени нет на такое извращение. Современные винты очень здорово работают по части скорости, время позиционирования небольшое, скорость диска тоже как и 20 лет назад, однако на одной дорожке данных НАМНОГО больше, потому скорость передачи достигает даже 200 Мб/с. С такой скоростью отдыхать не получается, единственное что выручает, так это контроллер DMA, заливающий данные в память независимо от CPU. К сожалению, его тоже надо программировать, чудес не бывает. И он довольно тупой и примитивный, даже из новых AHCI (кстати обрати внимание, 12309 появился точно тогда, когда появилась поддержка AHCI). Всё отлично работает, когда куски данных большие, но с малыми кусочками контроллер очевидно захлёбывается, ибо на это не заточен. NoWay. Это железо, с этим ничего не поделать.

Чем совершеннее контроллер DMA, тем дольше его программировать для чтения блока, и тем сильнее он _может_ тормозить всю систему. Лекарства нет, и быть не может в принципе. Мы специально жертвуем производительностью в этом редком юзкейсе для того, что-бы обеспечить производительность в остальных 99% случаев. Контроллер DMA имеет один из самых высоких приоритетов, и это вполне оправдано. Однако, если его долбить постоянно, то ВСЯ система становится раком. Что в этом странного? Не долби. Обеспечь свободное место, и отключи кривые «оптимизации».

он тебя наивного обманывает. Я сам параноик, потому знаю точно.

А какие оптимизации и, главное, дефолтные ванильные значения, существуют на счет данной подсистемы? Я бы рад отключить, но информацию по ядру даже из гугля выцарапать сложно, если ты не мейнтейнер интересующей тебя подсистемы.

У меня в десктопе Патрег так вот поставил:

# find /proc/sys/vm/ -printf "%f\t" -exec cat {} \;
vm/	cat: /proc/sys/vm/: Это каталог
block_dump	0
compact_memory	cat: /proc/sys/vm/compact_memory: Отказано в доступе
dirty_background_bytes	0
dirty_background_ratio	5
dirty_bytes	0
dirty_expire_centisecs	3000
dirty_ratio	10
dirty_writeback_centisecs	500
drop_caches	0
extfrag_threshold	500
laptop_mode	0
legacy_va_layout	0
lowmem_reserve_ratio	256	256	32
max_map_count	65530
min_free_kbytes	135168
mmap_min_addr	0
nr_pdflush_threads	0
oom_dump_tasks	1
oom_kill_allocating_task	0
overcommit_memory	0
overcommit_ratio	50
page-cluster	3
panic_on_oom	0
percpu_pagelist_fraction	0
scan_unevictable_pages	0
stat_interval	1
swappiness	60
vfs_cache_pressure	100

эти параметры и рекомендуют крутить в гугле. А я НЕ рекомендую.

Расшифровку надо искать в гугле, в сырцах, и чэйнжлоге. Там много букв. Я особо не вдавался, если честно. Что-то смотрел, что-то даже крутить пробовал, эффект обычно никакой или отрицательный.

а вот пресловутый курсор тормозит по той причине, что шина у нас ОДНА, даже если есть с десяток ядер. И если её постоянно долбить с вопросом к контроллеру DMA, то мышиным сигналам попросту не пробиться

Давно не читал такого бреда.

предложи своё объяснение 12309.

предложи своё объяснение 12309.

Хм. А до того ты будешь придерживаться своей неандертальской версии? Валяй, это даже забавно.

предложи своё объяснение 12309.

Что такое баг 12309? «Large I/O operations result in poor interactive performance and high iowait times» Под это определение попадает сто и одна причина почему это может быть в зависимости от еще ста причин и их комбинаций. У меня не проявлялось давно.

Хм. А до того ты будешь придерживаться своей неандертальской версии? Валяй, это даже забавно.

хорошо, поставим вопрос иначе: что я неправильно понимаю, и почему ты так категорично не согласен? Или сольёшься как Полиграф Полиграфыч, «несогласен во всём, с обоими!» Да?

Что такое баг 12309? «Large I/O operations result in poor interactive performance and high iowait times» Под это определение попадает сто и одна причина почему это может быть в зависимости от еще ста причин и их комбинаций. У меня не проявлялось давно.

у меня тоже. Но ведь проявлялось у тебя? Причины ты знаешь?

Разница только в этом куске:

max_map_count   65530
memory_failure_early_kill       0
memory_failure_recovery 1
min_free_kbytes 67584
min_slab_ratio  5
min_unmapped_ratio      1
mmap_min_addr   65536
nr_hugepages    0
nr_hugepages_mempolicy  0
nr_overcommit_hugepages 0
nr_pdflush_threads      0
numa_zonelist_order     default
oom_dump_tasks  1

Linux hostname 3.8.8-3-desktop #1 SMP PREEMPT Wed Apr 17 08:48:54 UTC 2013 (193f348) x86_64 x86_64 x86_64 GNU/Linux

что я неправильно понимаю

Работу шины.

почему ты так категорично не согласен?

Потому что блокирование транзакций устройства на шине в течение нескольких секунд невозможно (за искллючением ошибок в устройствах, конечно).

Мой ноут из саспенда выходит полторы секунды. Чяднт?

Причины ты знаешь?

Точно - нет. Подключить флешку не к фронтальной панели, а к заднему разъему, решало проблему. Теперь с любого нормально копирует, но той флешки уже нету.

я и не говорил про секунды. речь про микросекунды блокировки.

речь про микросекунды блокировки.

То есть вот это:

drBatty> пресловутый курсор тормозит

про микросекунды блокировки? Ахренеть вообще. И, по-твоему, в 12309 речь шла о блокировках на микросекунды? Ахрень вообще снова.

Подружку лучше заведи - сразу терабайт освободится :-D

Если она дешевле пачки HDD и адекватна, почему бы и нет? :}

Я вот купил SSD, но поставил на старую систему (была выше среднего на 2007г контроллеры SATA II, Pentium Core Duo E2140, DDR2), производительность выросла _на глаз_ эдак 25-30%.

на глаз?