[devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Shabalin]

День добрый.
Наши ядра собраны с такими параметрами.
CONFIG_PSI=y
CONFIG_PSI_DEFAULT_DISABLED=y
Есть ли возможность изменить настройку по-умолчанию в наших ядрах?
CONFIG_PSI_DEFAULT_DISABLED=n ?
Я знаю, что можно включить указанием при загрузке psi=1, но может
лучше сделать работающим по-умолчанию? Работа PSI нужна для
systemd-oom.


-- 
Alexey Shabalin

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey V. Vissarionov]

On 2021-09-06 15:41:20 +0300, Alexey Shabalin wrote:

 > Наши ядра собраны с такими параметрами.
 > CONFIG_PSI=y
 > CONFIG_PSI_DEFAULT_DISABLED=y

Для дистрибутивного ядра это абсолютно правильно: поддержка
есть, кому нужно - прочитают Documentation/accounting/psi.rst
и включат сбор этой информации явно.

 > Есть ли возможность изменить настройку по-умолчанию в наших
 > ядрах?

Лучше этого не делать.

 > CONFIG_PSI_DEFAULT_DISABLED=n ?

Вообще-то # CONFIG_PSI_DEFAULT_DISABLED is not set :-)

 > Я знаю, что можно включить указанием при загрузке psi=1,

Именно так и следует делать.

 > но может лучше сделать работающим по-умолчанию?

Лучше не надо. Как и любые другие виды accounting'а.

 > Работа PSI нужна для systemd-oom.

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


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

Добрый день!

On Mon, 6 Sep 2021 15:41:20 +0300 Alexey Shabalin wrote:
> День добрый.
> Наши ядра собраны с такими параметрами.
> CONFIG_PSI=y
> CONFIG_PSI_DEFAULT_DISABLED=y
> Есть ли возможность изменить настройку по-умолчанию в наших ядрах?
> CONFIG_PSI_DEFAULT_DISABLED=n ?
> Я знаю, что можно включить указанием при загрузке psi=1, но может
> лучше сделать работающим по-умолчанию? Работа PSI нужна для
> systemd-oom.

А оверхед за чей счёт будет? Кому нужно, пусть те и включают. 

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

Здравствуйте!

On 06.09.2021 17:04, Andrey Savchenko wrote:

>> Я знаю, что можно включить указанием при загрузке psi=1, но может
>> лучше сделать работающим по-умолчанию? Работа PSI нужна для
>> systemd-oom.

Уточню. PSI нужна для обеспечения стабильности системы в условиях, когда
не хватает ресурсов (прежде всего памяти). Без подсказки ядра у приложений
мало шансов узнать, что память закончилась. Поэтому странно, что у нас
до сих пор PSI отключена.

> А оверхед за чей счёт будет? Кому нужно, пусть те и включают.
А давайте заодно /proc/loadavg отключим, "оверхед" же. А кому надо - пусть
те и включают. (Шутка, если что, а то вдруг кто-то побежит отключать).

Хоть с PSI, хоть без ядро всё равно ведёт учёт занятой/доступной памяти.
А планировщик всё равно отслеживает, сколько потоков готово к выполнению,
сколько заблокированы, и т.п. C PSI ядро может предоставить эту информацию
в userspace.

Так что пусть по умолчанию будет включено. А кто хочет рискнуть стабильностью
системы ради (мнимого) прироста производительности - пусть **отключают**. 
Вместе с /proc/loadavg

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2541 bytes --]

On Mon, 6 Sep 2021 18:32:00 +0400 Alexey Sheplyakov wrote:
> Здравствуйте!
> 
> On 06.09.2021 17:04, Andrey Savchenko wrote:
> 
> >> Я знаю, что можно включить указанием при загрузке psi=1, но может
> >> лучше сделать работающим по-умолчанию? Работа PSI нужна для
> >> systemd-oom.
> 
> Уточню. PSI нужна для обеспечения стабильности системы в условиях, когда
> не хватает ресурсов (прежде всего памяти). Без подсказки ядра у приложений
> мало шансов узнать, что память закончилась. Поэтому странно, что у нас
> до сих пор PSI отключена.
> 
> > А оверхед за чей счёт будет? Кому нужно, пусть те и включают.
> А давайте заодно /proc/loadavg отключим, "оверхед" же. А кому надо - пусть
> те и включают. (Шутка, если что, а то вдруг кто-то побежит отключать).
> 
> Хоть с PSI, хоть без ядро всё равно ведёт учёт занятой/доступной памяти.
> А планировщик всё равно отслеживает, сколько потоков готово к выполнению,
> сколько заблокированы, и т.п. C PSI ядро может предоставить эту информацию
> в userspace.

Это не так. Pressure stall accounting при выключенной опции ядро не
ведёт.

> Так что пусть по умолчанию будет включено. А кто хочет рискнуть стабильностью
> системы ради (мнимого) прироста производительности - пусть **отключают**. 
> Вместе с /proc/loadavg

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

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Anton V. Boyarshinov]

Добрый день

> Наши ядра собраны с такими параметрами.
> CONFIG_PSI=y
> CONFIG_PSI_DEFAULT_DISABLED=y

Эти параметры показались мне разумным умолчанием (возможность есть, но
выключена по умолчанию).

У меня нет определённого мнения о том, следует ли включать это по
умолчанию, так как я совершенно не представляю себе какой оверхед это
повлечёт в реальных условиях и, с другой стороны, затрудняют оценить
насколько это реально нужно (и весь systemd-oom).

Но с интересом выслушаю аргументы сторон и к каким-нибудь из них
прислушаюсь, но пока не знаю к каким.

> Есть ли возможность изменить настройку по-умолчанию в наших ядрах?
> CONFIG_PSI_DEFAULT_DISABLED=n ?
> Я знаю, что можно включить указанием при загрузке psi=1, но может
> лучше сделать работающим по-умолчанию? Работа PSI нужна для
> systemd-oom.
> 
> 

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 06.09.2021 19:03, Andrey Savchenko wrote:

>> Хоть с PSI, хоть без ядро всё равно ведёт учёт занятой/доступной памяти.
>> А планировщик всё равно отслеживает, сколько потоков готово к выполнению,
>> сколько заблокированы, и т.п. C PSI ядро может предоставить эту информацию
>> в userspace.
> 
> Это не так. Pressure stall accounting при выключенной опции ядро не
> ведёт.

В тех местах, где и так всё упирается в ввод-вывод (считая манипуляции
таблицами страниц), например, __perform_reclaim, __alloc_pages_direct_compact,
ядро вызывает psi_memstall_enter/psi_memstall_leave.
Которые по сути ставят/снимают флажок.

>> Так что пусть по умолчанию будет включено. А кто хочет рискнуть стабильностью
>> системы ради (мнимого) прироста производительности - пусть **отключают**. 
>> Вместе с /proc/loadavg
> 
> Надеюсь, вы понимаете разницу между общим счётчиком и детализацией
> для каждого процесса?

$ cat /proc/loadavg 
0.63 0.50 0.42 1/1546 251275

$ cat /proc/pressure/memory

some avg10=0.00 avg60=0.00 avg300=0.00 total=2657355
full avg10=0.00 avg60=0.00 avg300=0.00 total=1480309

Ровно та же детализация, что у loadavg. Только, грубо говоря,
есть loadavg ещё и для памяти и дисков (IO).

> Вообще, memory accounting в ядре затратен и без нужды лучше не использовать.

Парламент не место для дискуссий, ага. А ядро не место для учёта памяти.
Это надо отлить в граните.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 4224 bytes --]

On Mon, 6 Sep 2021 19:23:49 +0400 Alexey Sheplyakov wrote:
> On 06.09.2021 19:03, Andrey Savchenko wrote:
> 
> >> Хоть с PSI, хоть без ядро всё равно ведёт учёт занятой/доступной памяти.
> >> А планировщик всё равно отслеживает, сколько потоков готово к выполнению,
> >> сколько заблокированы, и т.п. C PSI ядро может предоставить эту информацию
> >> в userspace.
> > 
> > Это не так. Pressure stall accounting при выключенной опции ядро не
> > ведёт.
> 
> В тех местах, где и так всё упирается в ввод-вывод (считая манипуляции
> таблицами страниц), например, __perform_reclaim, __alloc_pages_direct_compact,
> ядро вызывает psi_memstall_enter/psi_memstall_leave.
> Которые по сути ставят/снимают флажок.

Это может быть несущественно при дисковом i/o (и то я не уверен на
счёт современных NVMe), но не стоит игнорировать манипуляции
с памятью: ядро делает дополнительный вызов, это создаёт лишний
переход или даже несколько, уменьшает эффективность использования
кеша и т.д. и т.п..
 
> >> Так что пусть по умолчанию будет включено. А кто хочет рискнуть стабильностью
> >> системы ради (мнимого) прироста производительности - пусть **отключают**. 
> >> Вместе с /proc/loadavg
> > 
> > Надеюсь, вы понимаете разницу между общим счётчиком и детализацией
> > для каждого процесса?
> 
> $ cat /proc/loadavg 
> 0.63 0.50 0.42 1/1546 251275
> 
> $ cat /proc/pressure/memory
> 
> some avg10=0.00 avg60=0.00 avg300=0.00 total=2657355
> full avg10=0.00 avg60=0.00 avg300=0.00 total=1480309
> 
> Ровно та же детализация, что у loadavg. Только, грубо говоря,
> есть loadavg ещё и для памяти и дисков (IO).

Там достаточно много run-time сбора телеметрии выходит. Это не так
безобидно, как кажется.
 
> > Вообще, memory accounting в ядре затратен и без нужды лучше не использовать.
> 
> Парламент не место для дискуссий, ага. А ядро не место для учёта памяти.
> Это надо отлить в граните.

Вместо отлива в граните Вы лучше разок сами ядро соберите
и почитайте описания задействованных при этом опций. Вот пример:

config MEMCG_SWAP_ENABLED
    bool "Swap controller enabled by default"
    depends on MEMCG_SWAP
    default y
    help
      Memory Resource Controller Swap Extension comes with its price in
      a bigger memory consumption. General purpose distribution kernels
      which want to enable the feature but keep it disabled by default
      and let the user enable it by swapaccount=1 boot command line
      parameter should have this option unselected.
      For those who want to have the feature enabled by default should
      select this option (if, for some reason, they need to disable it
      then swapaccount=0 does the trick).

Там что не весь учёт потребления памяти одинаково полезен.

Обратите внимание: для функциональности с побочными эффектами
предусмотрен флажок для вкл/выкл по-умолчанию — ну прямо как для
CONFIG_PSI.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Sergey Y. Afonin]

On Monday 06 September 2021, Alexey Sheplyakov wrote:

> Уточню. PSI нужна для обеспечения стабильности системы в условиях, когда
> не хватает ресурсов (прежде всего памяти). Без подсказки ядра у приложений
> мало шансов узнать, что память закончилась. Поэтому странно, что у нас
> до сих пор PSI отключена.

Система, в которой постоянно заканчивается память, это странная система.
Не очень нужная. У меня вот даже systemd нет, и вот впервые узнал, что 
я что-то теряю. Сделайте себе kernel-image-std-systemd что ли... :-)

-- 
С уважением, Сергей Афонин

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Vitaly Chikunov]

Anton,

On Mon, Sep 06, 2021 at 06:16:23PM +0300, Anton V. Boyarshinov wrote:
> 
> > Наши ядра собраны с такими параметрами.
> > CONFIG_PSI=y
> > CONFIG_PSI_DEFAULT_DISABLED=y
> 
> Эти параметры показались мне разумным умолчанием (возможность есть, но
> выключена по умолчанию).
> 
> У меня нет определённого мнения о том, следует ли включать это по
> умолчанию, так как я совершенно не представляю себе какой оверхед это
> повлечёт в реальных условиях и, с другой стороны, затрудняют оценить
> насколько это реально нужно (и весь systemd-oom).
> 
> Но с интересом выслушаю аргументы сторон и к каким-нибудь из них
> прислушаюсь, но пока не знаю к каким.

Вот кратко (2019):
  https://lore.kernel.org/all/20190129233617.16767-1-hannes@cmpxchg.org/T/#u
  (Почему-то этот патч забыли принять.)

Вот длинно (2018):
  https://lore.kernel.org/all/20181127165329.GA29728@cmpxchg.org/T/#u

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Anton V. Boyarshinov]

В Mon, 6 Sep 2021 19:57:21 +0300
Vitaly Chikunov <vt@altlinux.org> пишет:

> Anton,
> 
> On Mon, Sep 06, 2021 at 06:16:23PM +0300, Anton V. Boyarshinov wrote:
> >   
> > > Наши ядра собраны с такими параметрами.
> > > CONFIG_PSI=y
> > > CONFIG_PSI_DEFAULT_DISABLED=y  
> > 
> > Эти параметры показались мне разумным умолчанием (возможность есть, но
> > выключена по умолчанию).
> > 
> > У меня нет определённого мнения о том, следует ли включать это по
> > умолчанию, так как я совершенно не представляю себе какой оверхед это
> > повлечёт в реальных условиях и, с другой стороны, затрудняют оценить
> > насколько это реально нужно (и весь systemd-oom).
> > 
> > Но с интересом выслушаю аргументы сторон и к каким-нибудь из них
> > прислушаюсь, но пока не знаю к каким.  
> 
> Вот кратко (2019):
>   https://lore.kernel.org/all/20190129233617.16767-1-hannes@cmpxchg.org/T/#u
>   (Почему-то этот патч забыли принять.)
> 
> Вот длинно (2018):
>   https://lore.kernel.org/all/20181127165329.GA29728@cmpxchg.org/T/#u

Спасибо! Но всё равно остаётся неясным то ли "не играет роли на
реальных задачах" то ли "6-10% потери производительности :(

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey V. Vissarionov]

On 2021-09-06 21:28:36 +0300, Anton V. Boyarshinov wrote:

 >>>> Наши ядра собраны с такими параметрами.
 >>>> CONFIG_PSI=y
 >>>> CONFIG_PSI_DEFAULT_DISABLED=y
 >>> Эти параметры показались мне разумным умолчанием
 >>> (возможность есть, но выключена по умолчанию).
 >> https://lore.kernel.org/all/20181127165329.GA29728@cmpxchg.org/T
 > Спасибо! Но всё равно остаётся неясным то ли "не играет роли
 > на реальных задачах" то ли "6-10% потери производительности :(

Как когда-то сказал папа Карла (Маркс), "практика - критерий истины".

Берем два одинаковых сервера (HP Proliant 360G7, 8 ядер E5530, 72 Гб
ОЗУ в каждом) из одного кластера, собираем ядра с вышеприведенными
параметрами, загружаемся (по очереди, чтобы нагрузка сначала на один
сервер легла, потом на второй, а потом снова балансироваться начала)
с psi=0 и psi=1 соответственно, смотрим, видим разницу в 3...4%. Не
фатально, конечно, но впустую греть атмосферу все же не хочется.

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

Если у кого-то есть результаты аналогичных экспериментов, будет очень
интересно на них посмотреть.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 06.09.2021 20:11, Sergey Y. Afonin wrote:

> Система, в которой постоянно заканчивается память, это странная система.
Это обычный Linux, в котором (по умолчанию) включён memory overcommit.
У ядра есть тумблер, чтобы отключить overcommit:

sysctl -w vm.overcommit_memory=2

Но потом предстоит долгая и бесперспективная борьба с userspace.

> Не очень нужная.

Давайте не будем решать за других, что нужно, а что - нет.

> У меня вот даже systemd нет, и вот впервые узнал, что я что-то теряю.

Век живи - век учись.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 06.09.2021 19:47, Andrey Savchenko wrote:

>> В тех местах, где и так всё упирается в ввод-вывод (считая манипуляции
>> таблицами страниц), например, __perform_reclaim, __alloc_pages_direct_compact,
>> ядро вызывает psi_memstall_enter/psi_memstall_leave.
>> Которые по сути ставят/снимают флажок.
> 
> Это может быть несущественно при дисковом i/o (и то я не уверен на
> счёт современных NVMe),

Будтье спокойны - от блокировок в blk никакой NVMe не поможет.

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

__perform_reclaim записывает "грязные" страницы на диск и изменяет
таблицы страниц. Задержки ввода-вывода (даже на nvme) на порядки больше,
чем какой-то там лишний вызов. А при изменениях таблицы страниц происходит
сброс кешей, так что уменьшить эффективность уже некак.

> Обратите внимание: для функциональности с побочными эффектами
> предусмотрен флажок для вкл/выкл по-умолчанию — ну прямо как для
> CONFIG_PSI.

Флажок, отключающий psi, предназначен для публики, которая меряется
результатами hackbench.

https://lore.kernel.org/all/20181127165329.GA29728@cmpxchg.org/T/#u

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 07.09.2021 00:49, Alexey V. Vissarionov wrote:

> Берем два одинаковых сервера (HP Proliant 360G7, 8 ядер E5530, 72 Гб
> ОЗУ в каждом) из одного кластера, собираем ядра с вышеприведенными
> параметрами, загружаемся (по очереди, чтобы нагрузка сначала на один
> сервер легла, потом на второй, а потом снова балансироваться начала)
> с psi=0 и psi=1 соответственно, смотрим, видим разницу в 3...4%.


С. Статистическая значимость.

А какая разница между этими серверами при psi=0? Не те же 3 -- 4%, а?

> Не фатально, конечно, но впустую греть атмосферу все же не хочется.

У. Устойчивость.

Расскажи лучше, что будет с этим сервером не то чтоб при DDoS, а нагрузке,
слегка (раза в 3 -- 4) превосходящей ожидаемую. 

Кому хочется рискнуть стабильностью системы ради мнимого роста
производительности - пожалуйста, отключайте psi, ставьте
vm.overcommit_memory=1, и далее со всеми остановками.

А вот в ядре по умолчанию так делать не надо.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Anton Farygin]

On 07.09.2021 10:46, Alexey Sheplyakov wrote:
> On 06.09.2021 20:11, Sergey Y. Afonin wrote:
>
>> Система, в которой постоянно заканчивается память, это странная система.
> Это обычный Linux, в котором (по умолчанию) включён memory overcommit.
> У ядра есть тумблер, чтобы отключить overcommit:
>
> sysctl -w vm.overcommit_memory=2
>
> Но потом предстоит долгая и бесперспективная борьба с userspace.
>
и overcommit на системах с sysvinit вылезает так же точно, как и на 
системах с systemd.

Особенно это неприятно на серверах. Просто сейчас память дешёвая и её 
довольно много и на серверах данная проблема у меня уже не проявляется.

На рабочих станциях нарываюсь на это постоянно.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Sergey Afonin]

On Tuesday 07 September 2021, Alexey Sheplyakov wrote:

> > Система, в которой постоянно заканчивается память, это странная система.

> Это обычный Linux, в котором (по умолчанию) включён memory overcommit.
> У ядра есть тумблер, чтобы отключить overcommit:
> 
> sysctl -w vm.overcommit_memory=2
> 
> Но потом предстоит долгая и бесперспективная борьба с userspace.

Эта проблема решается мониторингом и своевременным походом в магазин.
В случае, если время упущено, можно добавить swap-файл (сейчас я 
отправил в Sisypus пакет swapd, который может позаботиться об этом
автоматически; приложение, вообще-то, древнее).

> > Не очень нужная.
> 
> Давайте не будем решать за других, что нужно, а что - нет.

Так Вы же пытаетесь.

> > У меня вот даже systemd нет, и вот впервые узнал, что я что-то
> > теряю.
> 
> Век живи - век учись.

Придётся забыть на ненадобностью. ;-)

-- 
С уважением, Сергей Афонин.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Sergey Afonin]

On Tuesday 07 September 2021, Anton Farygin wrote:

> Особенно это неприятно на серверах. Просто сейчас память дешёвая и её 
> довольно много и на серверах данная проблема у меня уже не проявляется.

Вот-вот, но ядро зачем-то хотят этим загрузить для всех.

-- 
С уважением, Сергей Афонин.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 07.09.2021 14:17, Sergey Afonin wrote:
> On Tuesday 07 September 2021, Anton Farygin wrote:
> 
>> Особенно это неприятно на серверах. Просто сейчас память дешёвая и её 
>> довольно много и на серверах данная проблема у меня уже не проявляется.

Ребят, вы с какой планеты? Как там у вас, коммунизм уже наступил?

> Вот-вот, но ядро зачем-то хотят этим загрузить для всех.

Это вы хотите для всех поставлять по умолчанию нестабильную систему.
Ради больших показателей в  hackbench. Не слишком ли?

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey V. Vissarionov]

On 2021-09-07 13:31:28 +0400, Alexey Sheplyakov wrote:

 >> Берем два одинаковых сервера (HP Proliant 360G7, 8 ядер E5530,
 >> 72 Гб ОЗУ в каждом) из одного кластера, собираем ядра с
 >> вышеприведенными параметрами, загружаемся (по очереди, чтобы
 >> нагрузка сначала на один сервер легла, потом на второй, а
 >> потом снова балансироваться начала) с psi=0 и psi=1
 >> соответственно, смотрим, видим разницу в 3...4%.
 > С. Статистическая значимость.

М. Мимо.

 > А какая разница между этими серверами при psi=0? Не те же
 > 3 -- 4%, а?

Сотые доли процента. Я знаю, что использовать для тестов - благо,
выбор достаточно широкий.

 >> Не фатально, конечно, но впустую греть атмосферу все же не
 >> хочется.
 > У. Устойчивость.

О. Опыт эксплуатации.

 > Расскажи лучше, что будет с этим сервером не то чтоб при DDoS,

DDoS отстреливается на других серверах. Кстати, график загрузки
канала при этом выглядит забавно - на затухающие релаксационные
колебания похож.

 > а нагрузке, слегка (раза в 3 -- 4) превосходящей ожидаемую.

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

Специально для тебя:
А - администрирование
Б - балансировка нагрузки :-)

 > Кому хочется рискнуть стабильностью системы ради мнимого
 > роста производительности - пожалуйста, отключайте psi,

Как же это мы без него жили-то? До ядра 4.17, что ли...

И (о ужас!) до сих пор живем:

% zgrep CONFIG_PSI /proc/config.gz
# CONFIG_PSI is not set

 > ставьте vm.overcommit_memory=1, и далее со всеми остановками.
 > А вот в ядре по умолчанию так делать не надо.

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

Или не будет: К - как получится :-)

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


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Sergey Afonin]

On Tuesday 07 September 2021, Alexey Sheplyakov wrote:

> > Вот-вот, но ядро зачем-то хотят этим загрузить для всех.
> 
> Это вы хотите для всех поставлять по умолчанию нестабильную систему.
 
Эта "нестабильная" система была у меня перезагружена, например,
в воскресенье после 700 дней аптайма. На секундочку почтовый сервер,
который обслуживает наших клиентов, так что отнюдь не простаивает,
DoS держит и т.п. Шлюзы стоят годами под нагрузкой. Но можно дальше
придумывать про стабильность и костыли.

-- 
С уважением, Сергей Афонин.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 07.09.2021 14:16, Sergey Afonin wrote:
> On Tuesday 07 September 2021, Alexey Sheplyakov wrote:
> 
>>> Система, в которой постоянно заканчивается память, это странная система.
> 
>> Это обычный Linux, в котором (по умолчанию) включён memory overcommit.
>> У ядра есть тумблер, чтобы отключить overcommit:
>>
>> sysctl -w vm.overcommit_memory=2
>>
>> Но потом предстоит долгая и бесперспективная борьба с userspace.
> 
> Эта проблема решается мониторингом

psi и есть такой мониторинг. И делается он там, где это эффективнее
всего - в ядре.

> и своевременным походом в магазин.

Извините, лишних денег у меня нет. Кормить производителей памяти
и прочего железа мне совершенно не интересно.

> В случае, если время упущено, можно добавить swap-файл (сейчас я 
> отправил в Sisypus пакет swapd, который может позаботиться об этом
> автоматически; приложение, вообще-то, древнее).

Он не только бесполезен, но и делает ситуацию ещё хуже: притворяется,
что памяти много, когда на самом деле она закончилась.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Sergey Afonin]

On Tuesday 07 September 2021, Alexey Sheplyakov wrote:

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

Ну так добавьте себе psi=1, а не всем.

-- 
С уважением, Сергей Афонин.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 07.09.2021 14:26, Alexey V. Vissarionov wrote:

>  > А какая разница между этими серверами при psi=0? Не те же
>  > 3 -- 4%, а?
> 
> Сотые доли процента.

Так не бывает.

> DDoS отстреливается на других серверах. Кстати, график загрузки
> канала при этом выглядит забавно - на затухающие релаксационные
> колебания похож.
> 
>  > а нагрузке, слегка (раза в 3 -- 4) превосходящей ожидаемую.
> 
> При двухкратном увеличении нагрузки включится еще один сервер,
> стоящий в холодном резерве. Ну и начнется вывод дополнительных
> серверов из заморозки, разумеется.

То есть система управления ресурсами у тебя не в ядре, а извне.
Возможно, что в такой ситуации psi не очень нужен (хотя эти метрики
могут быть полезны для принятия решения о подключении доп. серверов).

Но тем не менее - это очень, очень специальная ситуация. В большинстве
случаев ресурсами управляет именно ядро, и только оно. Поэтому это ты,
мил человек, на своём кластере отключай то, что тебе не нужно.
А не навязывай своё решение всему миру.

>  > Кому хочется рискнуть стабильностью системы ради мнимого
>  > роста производительности - пожалуйста, отключайте psi,
> 
> Как же это мы без него жили-то? До ядра 4.17, что ли...

1. Плохо.
2. Как *вы* живёте - это ваше личное дело, меня это не касается...
   до тех пор, пока вы не начинаете калечить дистрибутивное ядро.

> 
> И (о ужас!) до сих пор живем:
> 
> % zgrep CONFIG_PSI /proc/config.gz
> # CONFIG_PSI is not set

Сколько угодно, хоть застрелитесь - ваше право.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Leonid Krivoshein]

Привет!


06.09.2021 23:49, Alexey V. Vissarionov пишет:
> [...]
> Берем два одинаковых сервера (HP Proliant 360G7, 8 ядер E5530, 72 Гб
> [...]

<offtop>
На них АЛЬТ? Какой? Понимаю, что ядро оно и в Африке Linux.)
Про HP Proliant 360 уже ни раз спрашивали, поэтому интересуюсь.
</offtop>


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Sergey Afonin]

On Tuesday 07 September 2021, Alexey Sheplyakov wrote:

> 2. Как *вы* живёте - это ваше личное дело, меня это не касается...
>    до тех пор, пока вы не начинаете калечить дистрибутивное ядро.
 
Почему Вы считаете своё мнение единственно верным? Я вот считаю,
что дистрибутив вообще весь покалечили, внедрив systemd, и что?

-- 
С уважением, Сергей Афонин.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Anton Farygin]

On 07.09.2021 13:17, Sergey Afonin wrote:
> On Tuesday 07 September 2021, Anton Farygin wrote:
>
>> Особенно это неприятно на серверах. Просто сейчас память дешёвая и её
>> довольно много и на серверах данная проблема у меня уже не проявляется.
> Вот-вот, но ядро зачем-то хотят этим загрузить для всех.
>
Так ядро собирается среднее, устраивающее всех примерно одинаково. А 
проблема с выходом за  память очень жёсткая. Лучше чинить для всех.

Re: [devel] [JT] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Oleg Solovyov]

В письме от вторник, 7 сентября 2021 г. 13:26:17 MSK пользователь Alexey V. 
Vissarionov написал:
> On 2021-09-07 13:31:28 +0400, Alexey Sheplyakov wrote:
>  > С. Статистическая значимость.
>  > У. Устойчивость.
> М. Мимо.
> О. Опыт эксплуатации.
Сумо какое-то устроили.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Anton Farygin]

On 07.09.2021 13:21, Alexey Sheplyakov wrote:
> On 07.09.2021 14:17, Sergey Afonin wrote:
>> On Tuesday 07 September 2021, Anton Farygin wrote:
>>
>>> Особенно это неприятно на серверах. Просто сейчас память дешёвая и её
>>> довольно много и на серверах данная проблема у меня уже не проявляется.
> Ребят, вы с какой планеты? Как там у вас, коммунизм уже наступил?
Такой же как у вас. При коммунистах, кстати, памяти было мало и она была 
дорогой.
>
>> Вот-вот, но ядро зачем-то хотят этим загрузить для всех.
> Это вы хотите для всех поставлять по умолчанию нестабильную систему.
> Ради больших показателей в  hackbench. Не слишком ли?
>
>
Слишком конечно, надо psi включить по умолчанию с возможностью 
отключения через параметр ядру.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Anton Farygin]

On 07.09.2021 13:27, Alexey Sheplyakov wrote:
>> В случае, если время упущено, можно добавить swap-файл (сейчас я
>> отправил в Sisypus пакет swapd, который может позаботиться об этом
>> автоматически; приложение, вообще-то, древнее).
> Он не только бесполезен, но и делает ситуацию ещё хуже: притворяется,
> что памяти много, когда на самом деле она закончилась.

Это не правда. swap сильно облегчает ситуацию про overcommit'е и 
окончании памяти.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey V. Vissarionov]

On 2021-09-07 14:42:18 +0400, Alexey Sheplyakov wrote:

 >>> А какая разница между этими серверами при psi=0? Не те же
 >>> 3 -- 4%, а?
 >> Сотые доли процента.
 > Так не бывает.

Если делать с умом - даже между датацентрами бывает разница в
пределах пары процентов.

 >>> нагрузке, слегка (раза в 3 -- 4) превосходящей ожидаемую.
 >> При двухкратном увеличении нагрузки включится еще один
 >> сервер, стоящий в холодном резерве. Ну и начнется вывод
 >> дополнительных серверов из заморозки, разумеется.
 > То есть система управления ресурсами у тебя не в ядре, а извне.

Управление ресурсами происходит на всех уровнях - от приложений до
датацентров. Иначе это не управление, а профанация.

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

Теоретически - могут. На практике - что есть они, что нет их...

 > Но тем не менее - это очень, очень специальная ситуация.

Эта "очень специальная ситуация" покрывает почти 80% современного
рынка ИТ и продолжает разрастаться.

Игнорировать этот факт - мягко говоря, недальновидно.

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

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

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

В частности, у меня сейчас три личных сервера. Пока хватает.

 > Поэтому это ты, мил человек, на своём кластере отключай то,
 > что тебе не нужно. А не навязывай своё решение всему миру.

Не... это вы, маленькие домашние пользователи, включайте свои
хотелки на своих маленьких домашних компутерах :-)

 >>> Кому хочется рискнуть стабильностью системы ради мнимого
 >>> роста производительности - пожалуйста, отключайте psi,
 >> Как же это мы без него жили-то? До ядра 4.17, что ли...
 > 1. Плохо.
 > 2. Как *вы* живёте - это ваше личное дело, меня это не
 > касается... до тех пор, пока вы не начинаете калечить
 > дистрибутивное ядро.

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

03:00.0 Ethernet controller [0200]: Broadcom Limited NetXtreme
II BCM5709 Gigabit Ethernet [14e4:1639] (rev 20)
03:00.1 Ethernet controller [0200]: Broadcom Limited NetXtreme
II BCM5709 Gigabit Ethernet [14e4:1639] (rev 20)
04:00.0 Ethernet controller [0200]: Broadcom Limited NetXtreme
II BCM5709 Gigabit Ethernet [14e4:1639] (rev 20)
04:00.1 Ethernet controller [0200]: Broadcom Limited NetXtreme
II BCM5709 Gigabit Ethernet [14e4:1639] (rev 20)

Для хомячкового ядра это, наверное, еще допустимо, а вот для
дистрибутивного - как-то неаккуратненько... покалечили, ага.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 07.09.2021 15:01, Anton Farygin wrote:
> On 07.09.2021 13:27, Alexey Sheplyakov wrote:
>>> В случае, если время упущено, можно добавить swap-файл (сейчас я
>>> отправил в Sisypus пакет swapd, который может позаботиться об этом
>>> автоматически; приложение, вообще-то, древнее).
>> Он не только бесполезен, но и делает ситуацию ещё хуже: притворяется,
>> что памяти много, когда на самом деле она закончилась.
> 
> Это не правда. swap сильно облегчает ситуацию про overcommit'е и окончании памяти.
> 

Случается по-разному. Ядро вынуждено быть очень осторожным, поэтому
oom killer вмешивается слишком поздно. А если есть swap - то может
и ещё позже. И "лишний" swap просто продлевает мучения.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey V. Vissarionov]

On 2021-09-07 13:54:11 +0300, Leonid Krivoshein wrote:

 >> два одинаковых сервера (HP Proliant 360G7, 8 ядер E5530, 72 Гб
 > offtop На них АЛЬТ?

Разумеется. Так что не такой уж и оффтопик.

 > Какой?

Сизиф. Ну... в основном Сизиф :-)

 > Понимаю, что ядро оно и в Африке Linux

Есть нюансы :-)

 > Про HP Proliant 360 уже ни раз спрашивали, поэтому интересуюсь.

Еще бы... аппараты очень популярные.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Anton Farygin]

On 07.09.2021 14:31, Alexey Sheplyakov wrote:
> On 07.09.2021 15:01, Anton Farygin wrote:
>> On 07.09.2021 13:27, Alexey Sheplyakov wrote:
>>>> В случае, если время упущено, можно добавить swap-файл (сейчас я
>>>> отправил в Sisypus пакет swapd, который может позаботиться об этом
>>>> автоматически; приложение, вообще-то, древнее).
>>> Он не только бесполезен, но и делает ситуацию ещё хуже: притворяется,
>>> что памяти много, когда на самом деле она закончилась.
>> Это не правда. swap сильно облегчает ситуацию про overcommit'е и окончании памяти.
>>
> Случается по-разному. Ядро вынуждено быть очень осторожным, поэтому
> oom killer вмешивается слишком поздно. А если есть swap - то может
> и ещё позже. И "лишний" swap просто продлевает мучения.
>
Это не совсем так. Я одно время довольно долго жил без свопа вообще и 
экспериментировал с разными настройками overcommit, так вот могу сказать 
что приемлемого для рабочей станции поведения машины без свопа так и не 
нашёл.

Подключение свопа объёмом в ОЗУ в принципе убрало все проблемы с 
памятью, т.к. часто бывает что реальное превышение совсем небольшое и 
проще задействовать в своп, чем уйти в зависшее состояние из-за overcommit'а


Это было на 8GB ОЗУ на десктопе. На 16Gb ОЗУ достаточно своп в 1/2.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 07.09.2021 15:21, Alexey V. Vissarionov wrote:

>  > Поэтому это ты, мил человек, на своём кластере отключай то,
>  > что тебе не нужно. А не навязывай своё решение всему миру.
> 
> Не... это вы, маленькие домашние пользователи, включайте свои
> хотелки на своих маленьких домашних компутерах :-)

Результат подобного отношения к пользователям:

76% - windows, 16% - OS X. Linux < 2%.

Да, это вы сделали, (типа) "крутые" (типа) "админы". Радуйтесь.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Anton Farygin]

On 07.09.2021 14:41, Alexey Sheplyakov wrote:
> On 07.09.2021 15:21, Alexey V. Vissarionov wrote:
>
>>   > Поэтому это ты, мил человек, на своём кластере отключай то,
>>   > что тебе не нужно. А не навязывай своё решение всему миру.
>>
>> Не... это вы, маленькие домашние пользователи, включайте свои
>> хотелки на своих маленьких домашних компутерах :-)
> Результат подобного отношения к пользователям:
>
> 76% - windows, 16% - OS X. Linux < 2%.
>
> Да, это вы сделали, (типа) "крутые" (типа) "админы". Радуйтесь.

https://radar.yandex.ru/desktop?period=all&selected_rows=MQuG4L%252Ck0OF9T%252CYhb4p1

Всё ещё хуже, но потихоньку ситуация меняется.

Но дело тут не только в работе с памятью, к сожалению.

Re: [devel] [JT] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Leonid Krivoshein]

07.09.2021 13:59, Oleg Solovyov пишет:
> В письме от вторник, 7 сентября 2021 г. 13:26:17 MSK пользователь Alexey V.
> Vissarionov написал:
>> On 2021-09-07 13:31:28 +0400, Alexey Sheplyakov wrote:
>>   > С. Статистическая значимость.
>>   > У. Устойчивость.
>> М. Мимо.
>> О. Опыт эксплуатации.
> Сумо какое-то устроили.

В ядре столько параметров интересных, о дефолтах которых можно 
поспорить, но лучше не здесь это делать, а убеждать апстрим ядра. Потому 
что дефолты там, как правило, весьма разумные.


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

On Tue, 7 Sep 2021 14:56:09 +0400 Sergey Afonin wrote:
> On Tuesday 07 September 2021, Alexey Sheplyakov wrote:
> 
> > 2. Как *вы* живёте - это ваше личное дело, меня это не касается...
> >    до тех пор, пока вы не начинаете калечить дистрибутивное ядро.
>  
> Почему Вы считаете своё мнение единственно верным? Я вот считаю,
> что дистрибутив вообще весь покалечили, внедрив systemd, и что?
 
Не Вы один так считаете, однако, в дистрибутиве пошло следование за
популярными и востребованными в определённых кругах хотелками, вот
и результат.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]

On Tue, 7 Sep 2021 14:21:20 +0400 Alexey Sheplyakov wrote:
> On 07.09.2021 14:17, Sergey Afonin wrote:
> > On Tuesday 07 September 2021, Anton Farygin wrote:
> > 
> >> Особенно это неприятно на серверах. Просто сейчас память дешёвая и её 
> >> довольно много и на серверах данная проблема у меня уже не проявляется.
> 
> Ребят, вы с какой планеты? Как там у вас, коммунизм уже наступил?
> 
> > Вот-вот, но ядро зачем-то хотят этим загрузить для всех.
> 
> Это вы хотите для всех поставлять по умолчанию нестабильную систему.
> Ради больших показателей в  hackbench. Не слишком ли?

Вам привели результаты тестирования на реально эксплуатируемой
системе, а Вы продолжаете волынку про hackbench. Не ожидайте
серьёзного отношения к Вам после такого поведения.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Sergey Y. Afonin]

On Tuesday 07 September 2021, Anton Farygin wrote:

> > Вот-вот, но ядро зачем-то хотят этим загрузить для всех.
> >
> Так ядро собирается среднее, устраивающее всех примерно одинаково. А 
> проблема с выходом за  память очень жёсткая. Лучше чинить для всех.

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

-- 
С уважением, Сергей Афонин

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Sergey Y. Afonin]

On Tuesday 07 September 2021, Alexey Sheplyakov wrote:

> > Не... это вы, маленькие домашние пользователи, включайте свои
> > хотелки на своих маленьких домашних компутерах :-)
> 
> Результат подобного отношения к пользователям:
> 
> 76% - windows, 16% - OS X. Linux < 2%.
> 
> Да, это вы сделали, (типа) "крутые" (типа) "админы". Радуйтесь.

Мы и рады. Были.

-- 
С уважением, Сергей Афонин

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Anton Farygin]

On 07.09.2021 23:47, Sergey Y. Afonin wrote:
> On Tuesday 07 September 2021, Anton Farygin wrote:
>
>>> Вот-вот, но ядро зачем-то хотят этим загрузить для всех.
>>>
>> Так ядро собирается среднее, устраивающее всех примерно одинаково. А
>> проблема с выходом за  память очень жёсткая. Лучше чинить для всех.
> Только если система выходит за память, это плохо в любом случае.
> Починкой должно быть состояние невыхода за память, а не костыль
> для постоянной работы на границе.
>
firefox и thunderbird починить невозможно - на использование памяти в 
них  влияет то, какой контент смотрит пользователь и как.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 08.09.2021 00:47, Sergey Y. Afonin wrote:
> On Tuesday 07 September 2021, Anton Farygin wrote:
>
>> Так ядро собирается среднее, устраивающее всех примерно одинаково. А 
>> проблема с выходом за  память очень жёсткая. Лучше чинить для всех.
> 
> Только если система выходит за память, это плохо в любом случае.

Разве что для компьютера, который управляет ядерным реактором (но только 
на таких компьютерах нет Linux). А так-то - это обычное дело.

> Починкой должно быть состояние невыхода за память,

"Состояние невыхода за память" достижимо только тогда, когда ресурсов выделено
(гораздо) больше, чем необходимо. То самое "что там ещё надо для тетриса" [1]

[1] Приходит новый русский в компьютерный магазин: "32-ядерный Ryzen, 256 ГБ памяти,
    ну, и что там ещё надо для тетриса".

> а не костыль для постоянной работы на границе.

Извините, но это уже напоминает агрессивную рекламу вида "у кого не 128 ГБ - тот лох"

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 07.09.2021 19:15, Andrey Savchenko wrote:

> Вам привели результаты тестирования на реально эксплуатируемой системе

1. Это там, где на двух разных серверах результаты совпадают до долей процента?
   Извините, я (к сожалению) уже давно не верю в Деда Мороза.

<sarcasm>
2. кластер из "8 ядер E5530, 72 Гб ОЗУ в каждом" - да-да-да, это типичная
   рабочая станция, именно на неё и следует ориентироваться, выбирая конфиг
   для ядра std-def.
</sarcasm>

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Sergey Afonin]

On Wednesday 08 September 2021, Anton Farygin wrote:

> firefox и thunderbird починить невозможно - на использование памяти
> в них  влияет то, какой контент смотрит пользователь и как.
 
Это да, но для них своп и перезапуск. Для них другого пути нет. 5Гб
мне на день хватает, а потом закрыть до завтра.

-- 
С уважением, Сергей Афонин.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Sergey Afonin]

On Wednesday 08 September 2021, Alexey Sheplyakov wrote:

> > Починкой должно быть состояние невыхода за память,
> 
> "Состояние невыхода за память" достижимо только тогда, когда ресурсов выделено
> (гораздо) больше, чем необходимо. То самое "что там ещё надо для тетриса" [1]
> 
> [1] Приходит новый русский в компьютерный магазин: "32-ядерный Ryzen, 256 ГБ памяти,
>     ну, и что там ещё надо для тетриса".
> 
> > а не костыль для постоянной работы на границе.
> 
> Извините, но это уже напоминает агрессивную рекламу вида "у кого не 128 ГБ - тот лох"

На сервере может быть. На десктопе сейчас, кажется, меньше 4Гб планок нет, а надо
бы использовать все каналы, это значит 8, либо, если трёхканальная, 12. Как я рядом
написал, 5 уже весьма не плохо.

-- 
С уважением, Сергей Афонин.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Anton Farygin]

On 08.09.2021 11:36, Sergey Afonin wrote:
> On Wednesday 08 September 2021, Anton Farygin wrote:
>
>> firefox и thunderbird починить невозможно - на использование памяти
>> в них  влияет то, какой контент смотрит пользователь и как.
>   
> Это да, но для них своп и перезапуск. Для них другого пути нет. 5Гб
> мне на день хватает, а потом закрыть до завтра.
>
ну почему же нету ? как показала практика - слежение за памятью + своп 
на 8Gb ОЗУ можно спокойно жить с аптаймами до пары месяцев.

а вот без слежения за памятью раз в неделю были жёсткие фризы с 
перезагрузкой.

У меня сейчас используетя KDE-шное слежение за памятью, которое начинает 
всплывать когда памяти становится менее 10%.

Но решение с systemd выглядит интереснее (хотя и не отменяет KDE-шное).

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Anton Farygin]

On 08.09.2021 11:38, Sergey Afonin wrote:
> On Wednesday 08 September 2021, Alexey Sheplyakov wrote:
>
>>> Починкой должно быть состояние невыхода за память,
>> "Состояние невыхода за память" достижимо только тогда, когда ресурсов выделено
>> (гораздо) больше, чем необходимо. То самое "что там ещё надо для тетриса" [1]
>>
>> [1] Приходит новый русский в компьютерный магазин: "32-ядерный Ryzen, 256 ГБ памяти,
>>      ну, и что там ещё надо для тетриса".
>>
>>> а не костыль для постоянной работы на границе.
>> Извините, но это уже напоминает агрессивную рекламу вида "у кого не 128 ГБ - тот лох"
> На сервере может быть. На десктопе сейчас, кажется, меньше 4Гб планок нет, а надо
> бы использовать все каналы, это значит 8, либо, если трёхканальная, 12. Как я рядом
> написал, 5 уже весьма не плохо.
>
Это сильно зависит от того, как именно пользоваться браузером и почтой. 
У меня часто случается по 300-400 открытых вкладок. А thunderbird'у 
нужно  1.5Gb ОЗУ для своей работы.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 08.09.2021 12:36, Sergey Afonin wrote:
> On Wednesday 08 September 2021, Anton Farygin wrote:
> 
>> firefox и thunderbird починить невозможно - на использование памяти
>> в них  влияет то, какой контент смотрит пользователь и как.
>  
> Это да, но для них своп и перезапуск. Для них другого пути нет. 5Гб
> мне на день хватает, а потом закрыть до завтра.

В основном верно. Вопрос только в том, как именно сделать этот перезапуск.

1. Заставить пользователя непрерывно смотреть в top на потребление памяти?
   Делать ему больше нечего.
   А непрерывно запущенный top - это гораздо более затратно, чем psi.

2. Полагаться на oom killer? Он просыпается, когда уже "это п...ц, а п...ц неизлечим" [1],
   и работает по методу "наказание невиновных, награждение непричастных".

В userspace (при наличии адекватных метрик, таких, как psi) можно принять
решение раньше, и более точное (поскольку можно задать правила).


[1]

Приходит мужик к доктору, показывает прыщик.
Доктор: "Это фигня, а фигню мы не лечим".
Через неделю мужик снова приходит, весь в язвах.
Доктор: "Это п...ц, а п...ц неизлечим".

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 08.09.2021 12:38, Sergey Afonin wrote:
> On Wednesday 08 September 2021, Alexey Sheplyakov wrote:

>> Извините, но это уже напоминает агрессивную рекламу вида "у кого не 128 ГБ - тот лох"
> 
> На сервере может быть. На десктопе сейчас, кажется, меньше 4Гб планок нет

Десктоп - не обязательно огромный жужжащий ящик.
Есть одноплатники [1], маленькие тихие компьютеры (NUC'и там всякие), моноблоки.
А ещё есть 32-битные архитектуры.

[1] да, мы хотим, чтобы ядро std-def работало и на них

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Denis Medvedev]

В Wed, 8 Sep 2021 12:50:15 +0400
Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:

> On 08.09.2021 12:36, Sergey Afonin wrote:
> > On Wednesday 08 September 2021, Anton Farygin wrote:
> > 
> >> firefox и thunderbird починить невозможно - на использование памяти
> >> в них  влияет то, какой контент смотрит пользователь и как.
> >  
> > Это да, но для них своп и перезапуск. Для них другого пути нет. 5Гб
> > мне на день хватает, а потом закрыть до завтра.
> 
> В основном верно. Вопрос только в том, как именно сделать этот
> перезапуск.
> 
> 1. Заставить пользователя непрерывно смотреть в top на потребление
> памяти? Делать ему больше нечего.
>    А непрерывно запущенный top - это гораздо более затратно, чем psi.
> 
> 2. Полагаться на oom killer? Он просыпается, когда уже "это п...ц, а
> п...ц неизлечим" [1], и работает по методу "наказание невиновных,
> награждение непричастных".
> 
> В userspace (при наличии адекватных метрик, таких, как psi) можно
> принять решение раньше, и более точное (поскольку можно задать
> правила).
У меня было вот такая идея:
сейчас malloc делает две вещи
1) или выдает память
2) или говорит "нет памяти".
И у него вообще нет варианта
"сейчас нет, жду"
Вот мне бы интересно было, если бы malloc мог (при включении какой-либо
опции) при отсутствии памяти  ждать ее появления , выдавая процессу
SIGTSTP.
C таким поведением можно было бы вручную/автоматически убить или
корректно завершить другие процессы и потом сказать SIGCONT.
> 
> 
> [1]
> 
> Приходит мужик к доктору, показывает прыщик.
> Доктор: "Это фигня, а фигню мы не лечим".
> Через неделю мужик снова приходит, весь в язвах.
> Доктор: "Это п...ц, а п...ц неизлечим".
> 
> 
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Anton Farygin]

On 08.09.2021 12:11, Denis Medvedev wrote:
> C таким поведением можно было бы вручную/автоматически убить или
> корректно завершить другие процессы и потом сказать SIGCONT.

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

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 08.09.2021 13:11, Denis Medvedev wrote:
> В Wed, 8 Sep 2021 12:50:15 +0400
> У меня было вот такая идея:
> сейчас malloc делает две вещи
> 1) или выдает память
> 2) или говорит "нет памяти".
> И у него вообще нет варианта
> "сейчас нет, жду"
> Вот мне бы интересно было, если бы malloc мог (при включении какой-либо
> опции) при отсутствии памяти  ждать ее появления , выдавая процессу
> SIGTSTP.

Сколько примерно времени займёт адаптация userspace к новому поведению?
В частности, как определить те места, где ответ "сейчас нет, жду" заведомо неприемлем?

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Sergey Afonin]

On Wednesday 08 September 2021, Alexey Sheplyakov wrote:

> Есть одноплатники [1], маленькие тихие компьютеры (NUC'и там
> всякие), моноблоки. А ещё есть 32-битные архитектуры.
> 
> [1] да, мы хотим, чтобы ядро std-def работало и на них
 
И вот это - частный случай. И тут можно добавлять параметр ядра.
А не всем подряд. Это раз.

А два - на них тоже бывает ФиреФокс? :-) А что касается NUC, там
что, меньше 4Гб ещё возможно сделать?

-- 
С уважением, Сергей Афонин.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Denis Medvedev]

В Wed, 8 Sep 2021 13:17:06 +0400
Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:

> On 08.09.2021 13:11, Denis Medvedev wrote:
> > В Wed, 8 Sep 2021 12:50:15 +0400
> > У меня было вот такая идея:
> > сейчас malloc делает две вещи
> > 1) или выдает память
> > 2) или говорит "нет памяти".
> > И у него вообще нет варианта
> > "сейчас нет, жду"
> > Вот мне бы интересно было, если бы malloc мог (при включении
> > какой-либо опции) при отсутствии памяти  ждать ее появления ,
> > выдавая процессу SIGTSTP.
> 
> Сколько примерно времени займёт адаптация userspace к новому
> поведению? В частности, как определить те места, где ответ "сейчас
> нет, жду" заведомо неприемлем?
"сейчас нет, жду" - это не ответ, не код возврата, это поведение.

А почему вообще userspace это интересно? Ему malloc возвратит память -
чаще чем обычно. И всё. Оно просто чаще не получит NULL, его либо
снимут явным kill ВНУТРИ malloc либо дадут памяти и волшебный пендель
SIGCONT. Зато это явно безопаснее, чем если далее не будет проверен код
возврата и будет разыменован NULL.
Привеите пример ситуации, когда ответ "сейчас нет, жду" хуже чем 
"нет памяти"?

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Denis Medvedev]

В Wed, 8 Sep 2021 12:12:46 +0300
Anton Farygin <rider@basealt.ru> пишет:

> On 08.09.2021 12:11, Denis Medvedev wrote:
> > C таким поведением можно было бы вручную/автоматически убить или
> > корректно завершить другие процессы и потом сказать SIGCONT.  
> 
> Кто ж вам даст это сделать из процесса, которому для этого нужна
> память ?
Зачем из этого процесса? Можно отслеживать демоном процессы, которые 
внезапно получают SIGSTOP и оповещать оператора. Пусть он разумно даст
им памяти. Или malloc может поднять какой-то флажок у процесса в sysfs
"жду памяти".

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Anton Farygin]

On 08.09.2021 12:40, Sergey Afonin wrote:
> On Wednesday 08 September 2021, Alexey Sheplyakov wrote:
>
>> Есть одноплатники [1], маленькие тихие компьютеры (NUC'и там
>> всякие), моноблоки. А ещё есть 32-битные архитектуры.
>>
>> [1] да, мы хотим, чтобы ядро std-def работало и на них
>   
> И вот это - частный случай. И тут можно добавлять параметр ядра.
> А не всем подряд. Это раз.
>
> А два - на них тоже бывает ФиреФокс? :-) А что касается NUC, там
> что, меньше 4Гб ещё возможно сделать?
>
4Gb это мало, очень мало для firefox ;) И да, на arm тоже есть firefox.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 08.09.2021 14:17, Denis Medvedev wrote:
> В Wed, 8 Sep 2021 12:12:46 +0300
> Anton Farygin <rider@basealt.ru> пишет:
> 
>> On 08.09.2021 12:11, Denis Medvedev wrote:
>>> C таким поведением можно было бы вручную/автоматически убить или
>>> корректно завершить другие процессы и потом сказать SIGCONT.  
>>
>> Кто ж вам даст это сделать из процесса, которому для этого нужна
>> память ?
> Зачем из этого процесса?

> Можно отслеживать демоном процессы, которые внезапно получают SIGSTOP

Как понять, что это именно "внезапно".

> и оповещать оператора.

Чтобы оповестить оператора нужна память => malloc => SIGSTOP => ОЙ!

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]

On Wed, 8 Sep 2021 13:01:13 +0400 Alexey Sheplyakov wrote:
> On 08.09.2021 12:38, Sergey Afonin wrote:
> > On Wednesday 08 September 2021, Alexey Sheplyakov wrote:
> 
> >> Извините, но это уже напоминает агрессивную рекламу вида "у кого не 128 ГБ - тот лох"
> > 
> > На сервере может быть. На десктопе сейчас, кажется, меньше 4Гб планок нет
> 
> Десктоп - не обязательно огромный жужжащий ящик.
> Есть одноплатники [1], маленькие тихие компьютеры (NUC'и там всякие), моноблоки.
> А ещё есть 32-битные архитектуры.
> 
> [1] да, мы хотим, чтобы ядро std-def работало и на них

Я вполне живу на 32-bit Atom с 2GB RAM и
# CONFIG_PSI is not set

Так что сказки не нужно рассказывать.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Oleg Solovyov]

В письме от среда, 8 сентября 2021 г. 13:17:21 MSK пользователь Denis Medvedev 
написал:
> Зачем из этого процесса? Можно отслеживать демоном процессы, которые
> внезапно получают SIGSTOP

Может быть, SIGTSTP, или это была опечатка?

man 7 signal:
> SIGSTOP      P1990      Stop    Stop process
> SIGTSTP      P1990      Stop    Stop typed at terminal
> [...]
> The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 08.09.2021 14:14, Denis Medvedev wrote:
> В Wed, 8 Sep 2021 13:17:06 +0400

>>> Вот мне бы интересно было, если бы malloc мог (при включении
>>> какой-либо опции) при отсутствии памяти  ждать ее появления ,
>>> выдавая процессу SIGTSTP.
>>
>> Сколько примерно времени займёт адаптация userspace к новому
>> поведению? В частности, как определить те места, где ответ "сейчас
>> нет, жду" заведомо неприемлем?
> "сейчас нет, жду" - это не ответ, не код возврата, это поведение.

Тогда это ещё хуже.

> А почему вообще userspace это интересно?

1. Потому что время имеет значение.
2. Приход сигнала, в том месте, где его не ожидает - это очень, очень плохо.

> Ему malloc возвратит память - чаще чем обычно. И всё. Оно просто чаще не получит NULL, его либо
> снимут явным kill ВНУТРИ malloc либо дадут памяти и волшебный пендель
> SIGCONT. Зато это явно безопаснее, чем если далее не будет проверен код
> возврата и будет разыменован NULL.

С точностью до наоборот: появляется ещё одно место, где возможен нелокальный
выход, и дополнительные возможности для атаки (я даже не говорю про DoS).

> Привеите пример ситуации, когда ответ "сейчас нет, жду" хуже чем 
> "нет памяти"?

С ходу:

pthread_mutex_lock(&mutex);
result = realloc(global_buf, size*2); /* и тут закончилась память */

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Denis Medvedev]

В Wed, 8 Sep 2021 14:27:46 +0400
Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:

> On 08.09.2021 14:17, Denis Medvedev wrote:
> > В Wed, 8 Sep 2021 12:12:46 +0300
> > Anton Farygin <rider@basealt.ru> пишет:
> > 
> >> On 08.09.2021 12:11, Denis Medvedev wrote:
> >>> C таким поведением можно было бы вручную/автоматически убить или
> >>> корректно завершить другие процессы и потом сказать SIGCONT.  
> >>
> >> Кто ж вам даст это сделать из процесса, которому для этого нужна
> >> память ?
> > Зачем из этого процесса?
> 
> > Можно отслеживать демоном процессы, которые внезапно получают
> > SIGSTOP
> 
> Как понять, что это именно "внезапно".
По выставлению флажка в sysfs
> 
> > и оповещать оператора.
> 
> Чтобы оповестить оператора нужна память => malloc => SIGSTOP => ОЙ!
Оповеститель может для себя зарезервировать кусок памяти ДО наступления
плохих событий.
> 
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Denis Medvedev]

В Wed, 8 Sep 2021 14:47:35 +0400
Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:

> On 08.09.2021 14:14, Denis Medvedev wrote:
> > В Wed, 8 Sep 2021 13:17:06 +0400
> 
> >>> Вот мне бы интересно было, если бы malloc мог (при включении
> >>> какой-либо опции) при отсутствии памяти  ждать ее появления ,
> >>> выдавая процессу SIGTSTP.
> >>
> >> Сколько примерно времени займёт адаптация userspace к новому
> >> поведению? В частности, как определить те места, где ответ "сейчас
> >> нет, жду" заведомо неприемлем?
> > "сейчас нет, жду" - это не ответ, не код возврата, это поведение.
> 
> Тогда это ещё хуже.
> 
> > А почему вообще userspace это интересно?
> 
> 1. Потому что время имеет значение.
Когда как. Поэтому такое поведение стоит включать явно каким-либо
специальным ключом компиляции, там где такое поведение не будет
фатальным.
> 2. Приход сигнала, в том месте, где его не ожидает - это очень, очень
> плохо.
Невыделение ожидаемой памяти обычно плохо не меньше.
> 
> > Ему malloc возвратит память - чаще чем обычно. И всё. Оно просто
> > чаще не получит NULL, его либо снимут явным kill ВНУТРИ malloc либо
> > дадут памяти и волшебный пендель SIGCONT. Зато это явно безопаснее,
> > чем если далее не будет проверен код возврата и будет разыменован
> > NULL.
> 
> С точностью до наоборот: появляется ещё одно место, где возможен
> нелокальный выход, и дополнительные возможности для атаки (я даже не
> говорю про DoS).
Нелокальный выход возможен всегда по получении SIGKILL. 
> 
> > Привеите пример ситуации, когда ответ "сейчас нет, жду" хуже чем 
> > "нет памяти"?
> 
> С ходу:
> 
> pthread_mutex_lock(&mutex);
> result = realloc(global_buf, size*2); /* и тут закончилась память */
Ну и что? Ну подождет realloc выделения памяти в системе и продолжит.
Что тут такого? Проблема будет если кто-то стопнутый процесс или
нить прибьет
- ну а никто не мешает его и просто так прибить SIGKILL-ом.
pthread_mutex_lock ведь касается только набора нитей, а следящий
процесс к этим нитям отношения не имеет и ему эти локи до лампочки.
Он отдельный процесс Linux если что. 
> 
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 08.09.2021 15:09, Denis Medvedev wrote:

>>> Можно отслеживать демоном процессы, которые внезапно получают
>>> SIGSTOP
>>
>> Как понять, что это именно "внезапно".
> По выставлению флажка в sysfs

Если хватит памяти выставить флажок в sysfs, ага.

>> Чтобы оповестить оператора нужна память => malloc => SIGSTOP => ОЙ!
> Оповеститель может для себя зарезервировать кусок памяти ДО наступления
> плохих событий.

А как он узнает, что "плохие события" ещё не наступили?
Что гарантирует, что резервирование пройдёт успешно?
А как зарезервировать память для всех компонент системы, которые необходимы для
оповещения (ну там, IP стек, драйвер Ethernet, и прочее)?
Как вообще выяснить, какие компоненты системы задействованы для оповещения?

Ответ я знаю -- вообще запретить динамическое выделение памяти (MISRA C),
но это уже будет не Linux (и стоимость разработки космическая).

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 08.09.2021 14:24, Anton Farygin wrote:
> On 08.09.2021 12:40, Sergey Afonin wrote:
>> On Wednesday 08 September 2021, Alexey Sheplyakov wrote:
>>
>>> Есть одноплатники [1], маленькие тихие компьютеры (NUC'и там
>>> всякие), моноблоки. А ещё есть 32-битные архитектуры.
>>>
>>> [1] да, мы хотим, чтобы ядро std-def работало и на них
>>   И вот это - частный случай.

Какая извращённая логика!
Кластер из серверов с over 9000 памяти - это, значит, общий случай.
А обычный компьютер - это "частный случай". 

>> А два - на них тоже бывает ФиреФокс? :-)

Да. И даже неплохо работает.

> А что касается NUC, там что, меньше 4Гб ещё возможно сделать?

1. Да, есть NUC'и с одним слотом памяти (и да, туда можно поставить 2ГБ).
2. NUC был приведен в качестве примера, кроме него есть много миниатюрных
   и одноплатных x86 компьютеров: atomic pi, rock pi x, и т.п.

> 4Gb это мало, очень мало для firefox ;) И да, на arm тоже есть firefox.

firefox нормально работает на rpi4 c 4 ГБ памяти.

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Anton Farygin]

On 08.09.2021 17:12, Alexey Sheplyakov wrote:
> On 08.09.2021 14:24, Anton Farygin wrote:
>>
>> 4Gb это мало, очень мало для firefox ;) И да, на arm тоже есть firefox.
> firefox нормально работает на rpi4 c 4 ГБ памяти.

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

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Sergey Y. Afonin]

On Wednesday 08 September 2021, Alexey Sheplyakov wrote:

> >>> [1] да, мы хотим, чтобы ядро std-def работало и на них

> >>   И вот это - частный случай.
> 
> Какая извращённая логика!
> Кластер из серверов с over 9000 памяти - это, значит, общий случай.
> А обычный компьютер - это "частный случай". 

Это у gremlin@ кластер, а у меня обычные сервера и обычные рабочие станции.
И на всё это единственный одноплатник, и тот у сына в столе валяется.

> 1. Да, есть NUC'и с одним слотом памяти (и да, туда можно поставить 2ГБ).
> 2. NUC был приведен в качестве примера, кроме него есть много миниатюрных
>    и одноплатных x86 компьютеров: atomic pi, rock pi x, и т.п.

В общем это всё - частные случаи, которые не выходят за погрешность.

-- 
С уважением, Сергей Афонин

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Alexey Sheplyakov]

On 08.09.2021 19:06, Sergey Y. Afonin wrote:
> On Wednesday 08 September 2021, Alexey Sheplyakov wrote:
>> Какая извращённая логика!
>> Кластер из серверов с over 9000 памяти - это, значит, общий случай.
>> А обычный компьютер - это "частный случай". 
> 
> Это у gremlin@ кластер, а у меня обычные сервера и обычные рабочие станции.

Ага, "обычные" рабочие станции с 32 ГБ оперативной памяти.
Всё ясно. Агрессивная реклама [1]. Дальнейшее обсуждение лишено смысла.

[1] Или антиреклама? "Linux - это такое г..., что для нормальной работы
    нужно 32 ГБ памяти, а лучше 64".

Re: [devel] Q: CONFIG_PSI_DEFAULT_DISABLED=y

[Sergey Y. Afonin]

On Wednesday 08 September 2021, Alexey Sheplyakov wrote:

> >> Кластер из серверов с over 9000 памяти - это, значит, общий случай.
> >> А обычный компьютер - это "частный случай". 
> > 
> > Это у gremlin@ кластер, а у меня обычные сервера и обычные рабочие станции.
> 
> Ага, "обычные" рабочие станции с 32 ГБ оперативной памяти.

Я вообще-то писал, что лично у меня 5 на рабочем. На домашнем 4, но я
его выключаю на ночь.  Но да, было бы надо, сходил бы в магазин за 
памятью.

А есть вот такой технический почтовик (туда всякие сообщения со всего сыпятся,
кто письма пишет: крон, копии боунсов почтовых и т.п.):

$ free
              total        used        free      shared  buff/cache   available
Mem:         243792       52432       52004          12      139356      182436
Swap:       1048284       21188     1027096

$ uname -a
Linux ... 5.4.143-std-def-alt1 #1 SMP Mon Aug 30 23:18:36 UTC 2021 i686 GNU/Linux


А это вот почтовик c абонентами, про который я ранее писал про 700 дней аптайма:

$ free
             total       used       free     shared    buffers     cached
Mem:       2063404    1993964      69440          0     300632     638496
-/+ buffers/cache:    1054836    1008568
Swap:      8193112     730272    7462840

-- 
С уважением, Сергей Афонин