Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"В ядре Linux 7.0 выявили регрессию, в два раза снижающую производительность PostgreSQL"	+/–
Сообщение от opennews (??), 04-Апр-26, 18:52
Инженер из компании Amazon выявил регрессию, специфичную для ядра Linux 7.0, релиз которого ожидается 13 апреля. Изменение настроек планировщика задач привело к существенному снижению пропускной способности и отзывчивости при работе  СУБД PostgreSQL на системах с архитектурой ARM64. При использовании ядра 7.0 показатели производительности при прохождении теста pgbench "simple-update" снизились почти в два раза - с 98565 до 50751... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=65143
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 04-Апр-26, 18:52	–2 +/–
>снизились почти в два раза Будут исправлять, что ещё делать. С другой стороны "enterprise" и так не побежит обновляться на свежие версии.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6

6. Сообщение от Аноним (6), 04-Апр-26, 19:01	+4 +/–
Они дали совет из разряда "купите более мощный комп".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

7. Сообщение от Аноним (7), 04-Апр-26, 19:02	+/–
И вот такое вот мы несём в Ubuntu 26.04 LTS?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #46

8. Сообщение от Аноним (8), 04-Апр-26, 19:03	+1 +/–
Будет причина сервера обновить. Стандартный подход.
Ответить | Правка | Наверх | Cообщить модератору

10. Сообщение от Tron is Whistling (?), 04-Апр-26, 19:08	+2 +/–
Так ядро не ухудшило работу и совместимость не сломало, надо править излишне заточенные на поведение ядра блокировки собственно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13

11. Сообщение от Аноним (1), 04-Апр-26, 19:08	+/–
Будут ждать корректирующего выпуска 26.04.1
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #12

12. Сообщение от Аноним (1), 04-Апр-26, 19:10	+/–
https://opennet.ru/64240-ubuntu
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

13. Сообщение от Аноним (-), 04-Апр-26, 19:24	–1 +/–
Stable API is nonsence, короче.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #67

14. Сообщение от Аноним (14), 04-Апр-26, 19:25	+12 +/–
В новости так расписано как PREEMPT_LAZY плохо влияет на постгрю, но при этом совсем не сказано для чего его добавляли и на что оно влияет позитивно. The introduction of PREEMPT_LAZY was for multiple reasons: - PREEMPT_RT suffered from over-scheduling, hurting performance compared to !PREEMPT_RT. - the introduction of (more) features that rely on preemption; like folio_zero_user() which can do large memset() without preemption checks. (Xen already had a horrible hack to deal with long running hypercalls) - the endless and uncontrolled sprinkling of cond_resched() Поэтому "решать" проблему через "вернуть по умолчанию режим PREEMPT_NONE" это фуфло. Ядро используется не только чтобы какие-то постри крутить. И они не должны быть приколачивать работу к дефолту.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #52, #74

15. Сообщение от FSA (ok), 04-Апр-26, 19:43	+/–
Отличные новости! Выявили! Значит исправят! Тем более даже у меня, на Fedora 44 до сих пор ядро 6.19. А другие дистрибутивы вообще более древние версии ядер используют. Так что когда они перейдут на версию 7.0 уже всё будет исправлено. Вспоминается, как глючил переключатель раскладки в Windows. Он глючил в Windows 2000, XP... и даже в Vista.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #35, #56, #64, #80, #81

16. Сообщение от Аноним (1), 04-Апр-26, 19:48	+/–
>до сих пор ядро 6.19 А какие ещё были ? https://www.kernel.org
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #17

17. Сообщение от Аноним (17), 04-Апр-26, 20:10	–1 +/–
>А какие ещё были ? Мог бы и сходить по своей то ссылке mainline:     7.0-rc6     2026-03-29
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #18

18. Сообщение от Аноним (1), 04-Апр-26, 20:19	+3 +/–
Ну ? Это же "RC" (release candidate). "Linux 7.0 релиз которого ожидается 13 апреля".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #87

19. Сообщение от eugener (ok), 04-Апр-26, 20:21	+6 +/–
Так это на arm, расходимся. Главное чтобы десктоп работал, а что там с БД — проблема сисадминов.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21, #34

20. Сообщение от Аноним (20), 04-Апр-26, 20:26	+2 +/–
>Perf profiling shows 55% of CPU time is consumed spinning in PostgreSQL's userspace spinlock (s_lock()) under PREEMPT_LAZY если в постгресе запилили спинлок в юзерспейсе (на что намекает этот коммент), то они по умолчанию не правы. Не надо так делать.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #43

21. Сообщение от Аноним (1), 04-Апр-26, 20:30	–1 +/–
>Так это на arm https://newsroom.ibm.com/2026-04-02-ibm-announces-strategic-...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

22. Сообщение от Аноним324 (ok), 04-Апр-26, 20:31	–5 +/–
> Пока не ясно какое решение примет Линус Торвальдс, который придерживается правила, что ядро не должно ухудшать работу и ломать совместимость с пространством пользователя. Так он каждый релиз ядра её ухудшает, и вообще стейб апи из нонсенс.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23, #28, #51

23. Сообщение от Аноним (23), 04-Апр-26, 20:36	+1 +/–
> Линус Торвальдс, который придерживается правила, что ядро не должно ухудшать работу и ломать совместимость с пространством пользователя. Опять читаем новость не тем местом...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

24. Сообщение от Аноним (24), 04-Апр-26, 20:36	+/–
А потом наёдут грязные хаки в PostgreSQL, обходящие планировщик. 146%
Ответить | Правка | Наверх | Cообщить модератору

25. Сообщение от User (??), 04-Апр-26, 21:12	+1 +/–
Этот Питер он вот откуда? Тут серьёзные человеки из платиновых спонсоров сказали, что "регрессия", а всякие там с @infraded.org говорят что "и так сойдет" - сейчас ГЛАВНЫЙ разберется как следует и "с присущим ему своеобразием" примет ПРАВИЛЬНОЕ решение.
Ответить | Правка | Наверх | Cообщить модератору

26. Сообщение от Аноним (26), 04-Апр-26, 21:25	+/–
Можно выпустить и так, но добавится гемор строителям дистров, т.к. при установке PostgeSQL им придется капсом писать для пользователей, что для корректной работы нужно другая версия ядра с PREEMPT_NONE или самим включать PREEMPT_NONE по дефолту. Да и вообще может выясниться, что на PREEMPT_LAZY можно забить.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #60, #68, #79

28. Сообщение от Аноним (28), 04-Апр-26, 21:42	+5 +/–
Тут API не меняется. Вы, очевидно, не в курсе, что такое API.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #38

34. Сообщение от dannyD (?), 04-Апр-26, 22:28	–9 +/–
>>Так это на arm, расходимся. Главное чтобы десктоп работал.... Вы до сих пор на x86 ? Вам еще не приташнивает? Мне уже давно, еще до эплсиликон...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #94

35. Сообщение от dannyD (?), 04-Апр-26, 22:30	+/–
>>до сих пор ядро 6.19 как бэ не совсем понятно - вы жалуетесь или хвастаетесь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

36. Сообщение от дворник (?), 04-Апр-26, 22:48	–12 +/–
Я так понимаю из-за этой шляпы сейчас "колбасит" (платежи не проходят, банкоматы наличку не дают) все банки, они-же с оракела переползли на постгри, и с интеля на арм. сбербанка и втбанка, если читаете эту новость, напишите, что это не так.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37, #39, #45, #53

37. Сообщение от Аноним (1), 04-Апр-26, 22:54	+/–
Погугли, узнаешь почему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

38. Сообщение от Аноним (6), 04-Апр-26, 23:12	+/–
Ещё как меняется: > автор изменений, из-за которых возникла регрессия ... заявил, что исправление нужно вносить в код PostgreSQL. ... посоветовал задействовать ... недавно добавленное в ядро расширение "rseq slice"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #42

39. Сообщение от ПростойФермерДжон (?), 04-Апр-26, 23:15	–1 +/–
Не не так,  сочетании с телеметрией нового Firefox, и profile-sync-daemon 7, пропускная способность осталась такой же, вот только данные дико сливают, не то чтобы мне жалко, но жалко траффика, и ого, я смотрел iotop, в новом firefox, за минуту наверное метров 500 скачивает). А да, точно, и все это на замечательном ядре 7.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #40, #41

40. Сообщение от Аноним (40), 04-Апр-26, 23:42	+/–
А что там за телеметрия?В релизе 149 ничего такого указано не было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #54

41. Сообщение от Аноним (1), 04-Апр-26, 23:43	+/–
Что ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

42. Сообщение от Аноним (28), 04-Апр-26, 23:53	+1 +/–
Даже слов не нахожу. Существующее API не изменилось. Как было так и осталось. Поменялись внутренние алгоритмы и добавилось новое API. Очевидно, вы никаком боком к разработке отношения не имеете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

43. Сообщение от Аноним (43), 04-Апр-26, 23:59	+2 +/–
Ты прав. В юзерспейсе вообще не надо использовать ничего из того, что предоставляет ядро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

45. Сообщение от Аноним (45), 05-Апр-26, 00:13	+1 +/–
Да все так ты прав. Эта хрень снизила в два раза перформанс всех тг прокси. Особенно 2.0beta которая из официального докера вообще не запускается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #65

46. Сообщение от Sem (??), 05-Апр-26, 00:32	+6 +/–
Справедливости ради, много ли у вас серверов на архитектуре ARM64?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #47, #58, #77, #82

47. Сообщение от Аноним (6), 05-Апр-26, 00:37	–2 +/–
Как бы даже в top500 есть на 7-ом месте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #50

50. Сообщение от Фняк (?), 05-Апр-26, 03:09	–1 +/–
Из разряда дать абсолютно верный, но бесполезный ответ. Кто в здравом уме на числодробилках из топ500 постгрес будет запускать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

51. Сообщение от Фняк (?), 05-Апр-26, 03:12	+/–
Ты бы хоть открыл тот файлик, на который ссылаешься. Там про внутриядерный апи
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #59

52. Сообщение от Аноним (52), 05-Апр-26, 03:29	+/–
А почему не PREEMPT_DYNAMIC?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

53. Сообщение от Аноним (53), 05-Апр-26, 04:18	–1 +/–
и ютуб, ютую поломала еще... до того как вышла
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

54. Сообщение от ПростойФермерДжон (?), 05-Апр-26, 06:17	+/–
Карочи щас не помню, какой то процесс, именно телеметрия. В iotop видно. Пробовал в firefox tarball. Те Firefox + Кеш + Какой то процесс именно телеметрия, отдельный, он непрерывно пишет на диск. Тоесть даже если отключить кеш, то этот процесс еще больше пишет чем кеш. А ну да, версия 151. Если оставить браузер, не листать интернет, то пишет непрерывно на диск, это уничтожает ресусрс ssd, ну и вообще номральн ли это, все равно что непрерывно копировать файлы в простое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #62, #85

56. Сообщение от Аноним (56), 05-Апр-26, 08:10	+/–
В старых нету закладок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

58. Сообщение от Anoni (?), 05-Апр-26, 08:13	+1 +/–
В Амазоне большинство постгресов крутится на Гравитоне...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

59. Сообщение от Аноним (56), 05-Апр-26, 08:16	+/–
А ты что древние тексты читать умеешь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

60. Сообщение от Аноним (56), 05-Апр-26, 08:19	+/–
Поэтому Майки финансируют Генту. Они лучше знают что лучше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

62. Сообщение от Аноним (62), 05-Апр-26, 08:29	+/–
В последнюю версию ещё АИ добавили
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

64. Сообщение от Zloy (ok), 05-Апр-26, 08:33	+/–
ничего никогда не глючило) Вообще выбор ядра зависит от требований, я перешел на линукс, когда увидел изменения в 6.19 которые мне были нужны. Не думаю, что стоит сразу перескакивать на новое ядро, обычно там много багов, которые обычные пользователи скорее всего не заметят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

65. Сообщение от Аноним (62), 05-Апр-26, 08:34	+/–
На Марс лети. Там нету блокировок интернета.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

67. Сообщение от Tron is Whistling (?), 05-Апр-26, 08:55	+/–
А там где-то API изменилось, или я что-то пропустил?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #75

68. Сообщение от Tron is Whistling (?), 05-Апр-26, 08:57    Скрыто ботом-модератором	+1 +/–
Ну выключат для арма PREEMPT_LAZY. Кто пострадает-то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

69. Сообщение от Tron is Whistling (?), 05-Апр-26, 09:00	+/–
Правильное название такое: в спинлоках постгрыза выявлена проблема, приводящая к снижению производительности на ядре 7 и арм.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #71

70. Сообщение от Аноним (71), 05-Апр-26, 09:04	+1 +/–
в линуксе настолько всратый IPC, что накостылить детсадовский спинлок лучше, чем пользоваться мутексами, семафорами и т.п.?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #86

71. Сообщение от Аноним (71), 05-Апр-26, 09:06	+1 +/–
ядро внезапно стало честно выдавать ресурсы, нужные для выполнения бесконечного цикла)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

72. Сообщение от Аноним (71), 05-Апр-26, 09:09	+/–
> Для устранения падения производительности он посоветовал задействовать в PostgreSQL недавно добавленное в ядро расширение "rseq slice" (Restartable Sequences) для ограничения вероятности вытеснения держателя блокировки. Пока дилетанты разбираются с костылями, профессионалы вовсю орудуют подпорками для костылей.
Ответить | Правка | Наверх | Cообщить модератору

73. Сообщение от Аноним (74), 05-Апр-26, 09:50	+/–
> Питер Зейлстра (Peter Zijlstra), автор изменений, из-за которых возникла регрессия, и мэйнтейнер планировщика задач и связанных с блокировками подсистем ядра, заявил, что исправление нужно вносить в код PostgreSQL. Удалять PREEMPT_NONE идиотизм, а совет переделать постгре показывает уровень разраба. Надеюсь Линус примет его стандартное в таким случаях решение.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #84

74. Сообщение от Аноним (74), 05-Апр-26, 09:54	+/–
PREEMPT и всякие RT это абсурд на многоядерных системах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #78, #90

75. Сообщение от Аноним (-), 05-Апр-26, 10:43	+/–
В широком смысле. От ядра ожидается предсказуемое поведение вообще-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #83

77. Сообщение от Аноним (-), 05-Апр-26, 11:27	+/–
> Справедливости ради, много ли у вас серверов на архитектуре ARM64? У вас может и немного. А у гуглов-амазонов-тенсентов и кого там еще - их уже очень даже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

78. Сообщение от Аноним (-), 05-Апр-26, 11:29	+/–
> PREEMPT и всякие RT это абсурд на многоядерных системах. Вообще-то PREEMPT_RT начиная с ядра 6.1 примерно дает именно RTOS'овые гарантии. Т.е что например на интервале X задача получит не менее Y процессорного времении. И ядро прошло довольно длинный путь чтобы достичь этого состояния. Потому что это не столько про 1 ядро и несколько, сколько про шедулинг, начинку ядра, blocking и проч.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

79. Сообщение от Аноним (-), 05-Апр-26, 11:31	+/–
> нужно другая версия ядра с PREEMPT_NONE или самим включать PREEMPT_NONE Блин, MSDOS поставьте - никто не будет вам preempt делать :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

80. Сообщение от ShpurloS (?), 05-Апр-26, 11:53	+/–
Так переключатель и в Windows 11 продолжает глючить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

81. Сообщение от zionist (ok), 05-Апр-26, 12:08	+/–
> даже у меня, на Fedora 44 до сих пор ядро 6.19 Fedora 44 ещё не вышла, у тебя максимум бета. А вот у меня на Fedora 43 ядро тоже 6.19 и со временем будет 7.0 ибо ядра тут обновляются всегда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

82. Сообщение от Анонисссм (?), 05-Апр-26, 12:33	+/–
>много ли у вас серверов на архитектуре ARM64? на самом деле Ampere Altra Max M128-30 окуенные. встречаются и у провайдеров VDS
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

83. Сообщение от Tron is Whistling (?), 05-Апр-26, 13:02	+1 +/–
Так оно и предсказуемое: всё работает. А вот то, что затюнили на конкретное микроповедение (тайминг), да ещё и конкретной платформы - ну это уже извиняйте, не проблемы ядра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #97

84. Сообщение от Tron is Whistling (?), 05-Апр-26, 13:03	+/–
Если проблемы только у одной поделки - переделывать придётся её, такие дела.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #92

85. Сообщение от Аноним (85), 05-Апр-26, 13:47	+/–
Так а в чём проблема? user_pref("browser.newtabpage.activity-stream.feeds.telemetry", false); user_pref("browser.newtabpage.activity-stream.telemetry", false); user_pref("app.normandy.enabled", false); user_pref("app.normandy.api_url", ""); user_pref("datareporting.policy.dataSubmissionEnabled", false); user_pref("datareporting.healthreport.uploadEnabled", false); user_pref("toolkit.telemetry.unified", false); user_pref("toolkit.telemetry.enabled", false); user_pref("toolkit.telemetry.server", "data:,"); user_pref("toolkit.telemetry.archive.enabled", false); user_pref("toolkit.telemetry.newProfilePing.enabled", false); user_pref("toolkit.telemetry.shutdownPingSender.enabled", false); user_pref("toolkit.telemetry.updatePing.enabled", false); user_pref("toolkit.telemetry.bhrPing.enabled", false); user_pref("toolkit.telemetry.firstShutdownPing.enabled", false); user_pref("toolkit.telemetry.coverage.opt-out", true); user_pref("toolkit.coverage.opt-out", true); user_pref("toolkit.coverage.endpoint.base", ""); Вот то, что каждые 5 секунд шебуршит жёсткими дисками, хотя никак их не касается, это отдельная проблема. Я долго думал, что это может быть запасной своп, но нет. Помогает убить контентные и гпу процессы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

86. Сообщение от Аноним (86), 05-Апр-26, 14:04	+/–
Это, скорее, говорит о качестве кода в постгре
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

87. Сообщение от Аноним (17), 05-Апр-26, 15:08	+/–
>Ну ? Это же "RC" (release candidate). Ну, терминалогические споры нас конечно заведут в метафизический тупик, но только сабжевых регрессий в ядрах 6.19 не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

90. Сообщение от Аноним (90), 05-Апр-26, 18:20	+1 +/–
Звукорежиссёры не согласны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

91. Сообщение от Аноним (91), 05-Апр-26, 18:57	+/–
да там того спинлока 200 строк кода всего. поправят за чашкой чая.
Ответить | Правка | Наверх | Cообщить модератору

92. Сообщение от Аноним (6), 05-Апр-26, 19:39	+/–
> проблемы только у одной поделки в винде таких регрессий нету.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

93. Сообщение от уп (?), 05-Апр-26, 19:47	+/–
Учёный вновь изнасиловал журналиста. https://lore.kernel.org/lkml/20260405144425.36044-1-kondo.mi.../ Проблема в конкретном коде Постгри для конкретной архитектуры.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #95, #99

94. Сообщение от Anonim (??), 05-Апр-26, 20:02	+1 +/–
Судя по минусам - местные эксперты ничего старше XP не видели ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

95. Сообщение от zionist (ok), 05-Апр-26, 20:07	+/–
Цитата от туда же: So I agree that the patch to retain PREEMPT_NONE is the right approach.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #96

96. Сообщение от уп (?), 05-Апр-26, 20:25	+/–
Не апстрим следует даунстриму, а даунстрим следует апстриму.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #98

97. Сообщение от Аноним (-), 05-Апр-26, 22:41	+/–
В два раза — это, извините, не «микро». Отдельно доставляет то, что ведь не какая-то поделка васяна с гитхаба отвалилась.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83

98. Сообщение от zionist (ok), 05-Апр-26, 23:23	+/–
Причём тут это? Mitsumasa говорит, что правильным решением, по его мнению, является патч ядра, возвращающий PREEMPT_NONE по дефолту.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

99. Сообщение от Аноним (99), 05-Апр-26, 23:38	+/–
Во-первых то сообщение опубликовано уже после выхода новости. Во-вторых по вашей ссылке ерунда написана, которую уже раскритиковали: https://lore.kernel.org/lkml/ccux4fgjcr626swwjwtdstxddkqjyxv.../ If I remove the rep nop on x86-64, the performance of the 4kB pages workload is basically unaffected, even with PREEMPT_LAZY. The spinning helps with workloads that are contended for very short amounts of time. But that's not the case in this workload without huge pages, instead of low 10s of cycles, we regularly spend a few orders of magnitude more cycles holding the lock. That's not to say the arm64 spin delay implementation is good. It just doesn't seem like it affects this case much.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема