Ты готов к снопам, $USER ?

Ну… Звучит вроде интересно, хотя и несколько мудрёно, и не особо понятно, насколько эффект будет в принципе заметен.

А к чему тут надо быть как-то особенно «готовым»?

Кликбейт?)))

Я надеюсь, это не какое-то патентованное решение, а чистый опен-сорс?

А к чему тут надо быть как-то особенно «готовым»?

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

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

:)

Это дополнительная прослойка поверх SLUB’а, которая будет кэшировать массивы данных для каждого CPU в отдельности, за счёт чего ожидается прирост производительности.

У меня один ЦПУ.

Для прозрачности можно добавить локальный блокчейн.

ожидается прирост производительности.

На сколько ожидается прирост?

Важное дополнение, спасибо, сразу видно современного вайб-программиста!

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

На сколько ожидается прирост?

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

Это зависит от задач. Прирост производительности будет не везде и не всегда. И в лучшем случае он может быть этак до 30%, а в самом лучшем случае до 50%. Разницу заметят в первую очередь админы highload серверов.

Звучит как-то слишком хорошо, чтобы быть правдой. Будто бы раньше специально плохо писали. Буду ждать популярных объяснений как это работает.

Мммм ожидаем новости об уязвимостях связанных с сбором «снопов» с соседних «полей».

Так ты ж новость принес, что там пишут в патче?

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

как это работает

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

Аргументировать, что оно «хорошо» != привести конкретные бенчмарки. Вон ниже saahriktu объясняет, почему это хорошо и полезно. Звучит логично и однозначно. А уж насколько будет прирост и в каких задачах — это уже потом померяют на всяких похорониксах, возможно хабрах, а может и тут умельцы найдутся.

У меня один ЦПУ.

Придётся купить второй!

https://youtu.be/BGLZQ_lHY2s?t=80

Я тебя умоляю, в Linux OOM киллер только недавно достаточно умный сделали... (В BSD и оффтопике он такой был аж с 80-х)

Я сегодня вот такое прочитал, тоже ничего не понял: https://medium.com/@theopinionatedev/linux-just-added-the-feature-macos-users-have-been-begging-for-8116bb29aad8

What Landed: Linux Kernel’s Per-Process GPU Scheduling

In Linux 6.11, the kernel officially introduced per-process GPU scheduling and memory accounting — essentially letting the system:

    Assign GPU resources to specific processes.
    Isolate GPU memory per application.
    Dynamically prioritize workloads without freezing the desktop.

It’s paired with updates in Mesa and Wayland compositors that let applications request GPU acceleration in a standardized way — no vendor hacks, no environment variables, no guessing games.

тогда готовься к kernel panic :)

Странно это. Казалось бы нужность включения фичи в майнлайн ядра должна быть обосновано в описании pr со ссылкой на тесты и методики тестирования

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

Которая будет жрать 99.9% всех cpu и поэтому задача сведется к «вот на том ядре остался 0.1% там и работай» :)

cpu

npu же :)

тебя умоляю, в Linux OOM киллер только недавно достаточно умный сделали... (В BSD и оффтопике он такой был аж с 80-х)

OOM killer в оффтопике в 80-х называлось «семь бед, один резет».

npu же :)

Ну или так :)

«семь бед, один резет».

В Windows это до сих пор и даже ресет помогает далеко невсегда?

а тут кэширование для конкретного CPU, на котором может выполняться только один поток.

Кто сказал? Как то же запускали многопоточные приложения до всей этой многоядерности. Или тут будут ещё и ядро пинить к потоку?

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

Так я о том и спрашиваю, для этой технологии нужно ещё и ядра пинить к потокам(процессам?)?

По ходу, да.

значить для rt и любителей отзывчивых интерфейсов не дайдёть

The per-NUMA-node cache of sheaves is thus called «barn».

Т.е. снопы будут складывать в амбары. Ещё сусеки добавить и будет норм.

БЕЛКА ИСТЕРИЧКА

Ты готов к снопам, $USER ?

Нет.

которая будет кэшировать массивы данных для каждого CPU в отдельности

Речь про ядра или прогопроцессорные системы. Если первое, то процесс может бросать с ядра на ядро вроде как, балансируя нагрузку, там что хотят прибивать гвоздями? Иначе ведь 1 тред может попрыгать по например 6 ядрам из шести и относительно каждого ядра подёргать разное, и так и будет прыгать дрыгая разное, причём одноразовое, ну и чего там за мусор оно накэширует, подзабив при этом я так понял памяти?

Это типа сделают L4d кэши, но в оперативке получается? Только в отличие от L3 кеша родного в процессоре общего на все ядра, в оперативке будут лежать банки памяти к которым были обращения недавно для подгрузки в L3 разбитые по ядрам?

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

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

На правах белки истерички я всё сказал, как там на самом деле, почувствуем на себе. Обладатели топовых камней может ничего и не заметят или увидят прирост со своей LDDR6 памятью десятигигагерцовой, а ми на фйеномах с ddr3 1333 буим стладать!

А может и нет :)

Не знаю, что там в Windows, а в Linux вроде так и есть, иначе не изобретали бы никаких systemd-oomd

про офтопик и 80-е - очень смешно ;-)

у меня есть подозрение, что он офтопик 80-х только на картинках видел.

bins?

про офтопик и 80-е - очень смешно ;-)

https://ru.wikipedia.org/wiki/Windows_NT_3.1#Разработка

Разработка Windows NT началась в ноябре 1988 года

https://ru.wikipedia.org/wiki/Windows_NT_3.1#Разработка
Разработка Windows NT началась в ноябре 1988 года

Только началась, а вот:

Первая публичная демонстрация Windows NT, тогда называвшейся Windows Advanced Server for LAN Manager, была представлена на конференции разработчиков в августе 1991 года[7], а формальное объявление продукта состоялось весной 1993 года на выставке COMDEX в Атланте, Джорджия.

В любом случае, в Linux OOM Killer работать адекватно начал года два как. В то время как везде его сразу делали нормально.

В то время как везде его сразу делали нормально.

Это вы про «Память не может быть read?» :)

Балин, я давно не пользуюсь FreeBSD, так бы показал тебе разницу кода OOM там (в версиях 2.2.x) и в ванильных Linux 4.xx (не говоря о 2.xx, где код вообще примитивный был).

Я вроде понятно намекнул совсем не фряху. :)

разработка! и NT!

а в ширнармассы что пошло, да ещё только в 1990?

совсем не фряху. :)

4.2BSD? В принципе, и в OS/2, и в NT OOM Killer не был простым костылём, который по кругу выкидывал процессы, включая telnetd и т.п.

Linux OOM Killer с шедулером до 20-х гг 21 века были простыми и убогими. MSDOS не претендовал на такое, а все конкуренты Linux, платные и бесплатные, имели сильно более замороченные алгоритмы.

причём тут OOMK и тот факт, что ты слажал с некими супер-планировщиками из 80-х?

и да - ты сам-то полумухой пользовался?