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

"Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэшированию запросов времени"	+/–
Сообщение от opennews (??), 16-Янв-24, 23:42
Jens Axboe, создатель io_uring и сопровождающий блочную подсистему в ядре Linux, смог увеличить число операций ввода/вывода в секунду (IOPS) как минимум на 6% (возможно больше на полновесных конфигурациях ядер Linux), потратив всего 5 минут на кодинг.... Подробнее: https://www.opennet.me/opennews/art.shtml?num=60445
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+80 +/–
Сообщение от Аноним (1), 16-Янв-24, 23:42
Выпиливание Snap увеличивает скорость ввода/вывода на 300%
Ответить | Правка | Наверх | Cообщить модератору

	3. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+25 +/–
	Сообщение от Alladin (?), 16-Янв-24, 23:50
	на 3000%
	Ответить | Правка | Наверх | Cообщить модератору

	8. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–27 +/–
	Сообщение от Аноним (8), 17-Янв-24, 00:11
	И увеличит время на установку и обновление проприетарного софта типа Zoom, Teams на 300000000%, не говоря уже про "загрязнение" системы.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	13. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–2 +/–
	Сообщение от Аноним (13), 17-Янв-24, 00:22
	>И увеличит время на установку и обновление проприетарного софта типа Zoom до +∞, так как софта в принципе не будет, а распространять неофициальные версии или прошлые официальные не с са1та копирайтоторговца - нарушение копирайта. Пофиксил.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (32), 17-Янв-24, 01:23
	А в чём подвох?
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+7 +/–
	Сообщение от Аноним (-), 17-Янв-24, 00:34
	yay -S teams zoom думаю, в убунтах будет три строчки вместо одной, но тоже никто не помрёт. а вот от тормозов snap помереть можно. мучительно. очень.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	20. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (8), 17-Янв-24, 00:45
	Думаю, в нормальных дистрибутивах ничего не будет. Flatpak, для проприетарщины, как firejail для wine - стандарт.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+2 +/–
	Сообщение от Аноним (23), 17-Янв-24, 01:03
	>как firejail для wine - стандарт. Проясните. У меня сандбоксинг виндовых приложений через firejail никогда не работал. Вайн даже не стартовала.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–1 +/–
	Сообщение от Аноним (8), 17-Янв-24, 01:43
	А в чем сложность? firejail --private=/home/user/Temp/sandbox/steam/ /usr/bin/steam
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (104), 17-Янв-24, 12:39
	В том, что я не --private, который создаёт виртуальный хомяк, использую, а --(no)?(white|black)list, --net и т.д. И не работают даже простейшие приложения, не говоря уже о Foxit Reader. К тому же всё это тщетно - одно приложение стартует кучу демонов вайна. Второе - подключается к тем же демонам. То есть засандбоксив одно приложение - остальные попадают в ту же песочницу. Это говорит о том, что не firejailом надо вайн оборачивать, а SandboxIE (он опенсорсный!) в сам вайн интегрировать.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от adolfus (ok), 17-Янв-24, 13:52
	Foxit Reader. Чем он лучше okular? Спрашиваю, потому что не пользуюсь.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (116), 17-Янв-24, 14:39
	Можно отключить JavaScript, можно редактировать закладки.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от adolfus (ok), 21-Янв-24, 00:46
	> Можно отключить JavaScript, можно редактировать закладки. А что, разве окуляр использует javascript? Окуляр имеет стековую систему навигации по документу. Ну и закладки тоже, разумеется. Плюс возможности рецензирования, вкладки, выделение и прочие интересные штучки. Ну и классический интерфейс.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (134), 17-Янв-24, 17:18
	> Это говорит о том, что не firejailом надо вайн оборачивать, а SandboxIE > (он опенсорсный!) в сам вайн интегрировать. Дружище, ты вообще представляешь себе, через какие механизмы работает SandboxIE, да и вообще раньше работали любые антивири в винде? Вайн юзермодный, толку в нём от сорцов SandboxIE? Не говоря уж о том, что это не песочница, это позорный дуршлаг, который пробивали неоднократно. Впрочем, направление мысли верное — то что по умолчанию wine не дропает все привелегии, которые только можно и не виртуализует пути, это бесит ещё с ранних версий. «Win32 PE as a first–class citizen», my ass.
	Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

	36. Скрыто модератором	–1 +/–
	Сообщение от Аноним (-), 17-Янв-24, 01:38
	под snap психически здоровые люди обычно подразумевают в том числе flatpack, appimage и в принципе всё, что там малолетние домохозяйки ещё набыдлокодили
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	49. Скрыто модератором	–2 +/–
	Сообщение от Аноним (8), 17-Янв-24, 04:30
	Да, я ставил Zoom на Debian, как deb пакет. В итоге при --fix-broken мне залетела какая-то эмоджи хрень, при закрытии которой переставала работать клавиатура. Не, ну I/O конечно быстрее, если его вообще нет. так что ускорение вышло просто феноменальное.
	Ответить | Правка | Наверх | Cообщить модератору

	102. Скрыто модератором	+/–
	Сообщение от rshadow (ok), 17-Янв-24, 12:17
	Да у них там "все сложно". В какой-то момент просто зафризил более менее стабильную версию и с ней жил.
	Ответить | Правка | Наверх | Cообщить модератору

	93. Скрыто модератором	–1 +/–
	Сообщение от Аноним (93), 17-Янв-24, 11:06
	ну ты то такой умный, что не сильно нужное 1 раз в месяц обязательно ставишь в систему (речь про appimage)
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	84. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–2 +/–
	Сообщение от Аноним (84), 17-Янв-24, 10:25
	Вылазит какая то древняя версия.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	92. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Umnik (?), 17-Янв-24, 11:05
	Ставится нерабочая версия Зума. По крайней мере ставилась в конце декабря, сейчас не проверял. Пришлось из tar.gz с офсайта ставить.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	120. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от 12yoexpert (ok), 17-Янв-24, 15:11
	там 500 версий этого зума, я проприетарью не пользуюсь, написал первый попавшийся
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от 12yoexpert (ok), 17-Янв-24, 15:12
	даже с firejail есть
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+3 +/–
	Сообщение от penetrator (?), 17-Янв-24, 06:30
	ненужное, ни то ни другое, на крайний случай из браузера зум откроешь, а тимс вообще не нужное, что может сделать корпорация убившая скайп? опомнись
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	60. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (60), 17-Янв-24, 06:53
	А что, скайпа нет уже? Хорошая новость. Проглядел как-то...
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от YetAnotherOnanym (ok), 17-Янв-24, 13:54
	Ходили слухи, что скайп перевели на ноду и уебртц (https://www.opennet.me/opennews/art.shtml?num=44783). Возможно, под "смертью скайпа" мсье Аноним имеет в виду именно это.
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+1 +/–
	Сообщение от Аноним (-), 17-Янв-24, 22:53
	> Возможно, под "смертью скайпа" мсье Аноним имеет в виду именно это. После перехода на супер-дупер веб технологии он утратил главное достоинтсво - "работает везде". После чего как-то стал всем нахрен нужен - с него все хомячки уже по сути и посваливали. Вот так парой очередных умных манагерских решений можно профачить один из самых популярных мессенжеров.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Самый Лучший Гусь (?), 19-Янв-24, 14:55
	Вобщемта именно после перехода не веб-технологии он и стал работать везде, то есть в хроме. А хром есть везде. До перехода на эти ужасные технологии скайп в линуксе выглядел и работал как убитый трактор.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (163), 21-Янв-24, 06:18
	> Вобщемта именно после перехода не веб-технологии он и стал работать везде, то > есть в хроме. А хром есть везде. Ты не понял. Я имел в виду "дурные сетевый конфигурации". Скайп находил дорожку в сеть почти через что угодно. Даже через соседа в LAN, если у него выход в инет и скайп были. Рестриктивные corp сетки, кафешки с недоогороженой фафлей, you name it. Оно просто работало! В режиме плагнплея. Сложноудавимо для админов. Особо принципиальные, конечно, ухитрялись и это - но канители много. Поэтом в целом работало, даже в условиях типа повернутых на безопасности корп сеток. > До перехода на эти ужасные технологии скайп в линуксе выглядел и работал как убитый трактор. А теперь это просто кусок ненужной веб фигни от майкрософт. Без каких-то особенных достоинств вообще. Ну им никто и не пользуется уже почти, соответственно, +1 технология профуканая MS.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–3 +/–
	Сообщение от Vasya (??), 17-Янв-24, 08:03
	Это вы, батенька, в реалиях рф. В западных компаниях тимс это приложение по-умолчанию для конференций. Иногда еще встречается вебекс, но в основном, 99% конференций всегда будут в тимс. Скажу даже больше, на тимс  переходят многие даже в качестве замены внутренней телефонии, а pstn сип транки заводятся через direct routing.
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

	78. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+3 +/–
	Сообщение от Бывалый смузихлёб (?), 17-Янв-24, 09:20
	> В западных компаниях тимс это приложение по-умолчанию для конференций Ну а почему бы и нет. Лоббизм и завязывание всех на своей инфраструктуре - оно такое
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–3 +/–
	Сообщение от Аноним (-), 17-Янв-24, 12:36
	Или отказ пользоваться унылым овном слепленным на коленке васянами и дизайненным бомжом после делирия. Назови какой-то аналог тимс, только открытый? Мне было бы интересно посмотреть на это чудо.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от penetrator (?), 17-Янв-24, 14:00
	> Или отказ пользоваться унылым овном слепленным на коленке васянами и дизайненным бомжом > после делирия. > Назови какой-то аналог тимс, только открытый? > Мне было бы интересно посмотреть на это чудо. не знаю, что ты имеешь ввиду под аналогом, но видеоконференцию можно сделать даже в Signal, со всей его надежностью и безопасностью и что там с Матриксом? не работает?
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+1 +/–
	Сообщение от User (??), 17-Янв-24, 15:22
	Ну, если "для себя и кота" - то норм, работает. А если человек хотя бы 200 и часть из них - не из твоей организации - то уже не очень-то.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Vasya (??), 17-Янв-24, 15:56
	Дело не в том, что нет альтернатив Тимсу, а в том, что все его используют. Вот пользователю приходит приглашение на встречу в тимс, и не просто от какого-нибудь рядового сотрудника, а от важных бизнес-партнеров, ты будешь им затирать про то что есть альтернативы и не надо использовать тимс, потому что он кусок говна? Открою секрет - айти это обслуживающий персонал, а деньги зарабатывают те самые, кто хотят использовать тимс, потому что все их партнеры его используют. И у тебя альтернатива - либо работать с тем что удобно пользователям или вылететь с очень-очень хорошо оплачиваемой работы.
	Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

	118. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от User (??), 17-Янв-24, 14:53
	Ну, ты эта... походи по базару, поищи что лучше. jitsi или там какой apache openmeeting не предлагать, ок?
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	59. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (60), 17-Янв-24, 06:53
	> установку ... проприетарного софта типа Zoom, Teams ... "загрязнение" системы. Так лучше. Нет?
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	72. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (72), 17-Янв-24, 08:30
	Не увеличит. Снап не единственный и худший среди альтернатив по контейнерам (это если без мусора). А если с нативом сравнивать так контейнеры всегда проигрывают и по скорости установки и тем более по скорости обновления by design.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	85. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+1 +/–
	Сообщение от Аноним (84), 17-Янв-24, 10:27
	Куда ты торопишься? У тебя что там конкурс на скорость открытия программ?
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+2 +/–
	Сообщение от Аноним (-), 17-Янв-24, 01:23
	> Выпиливание Snap увеличивает скорость ввода/вывода на 300% А если у меня его нет - тогда придется, вот, как лоху, 6% довольствоваться. Но те 300% я же и не просирал :)
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	41. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–1 +/–
	Сообщение от Kuromi (ok), 17-Янв-24, 02:00
	Если ты на *бунточке, то расслабься, там периодически идут разговоры о том чтобы перевести все на шнапсы. Опять же идейки продвигать Ubuntu Core на десктоп уже озвучивались на этот год. При этом, ЧСХ, сразу же признание что tinkerers будут недовольны потому что контроль тю-тю.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+1 +/–
	Сообщение от Аноним (-), 17-Янв-24, 02:16
	> Если ты на *бунточке, то расслабься, там периодически идут разговоры о том > чтобы перевести все на шнапсы. Я на дебиане. Облом, да? "И пусть эта тля подавится!" :) > Опять же идейки продвигать Ubuntu Core > на десктоп уже озвучивались на этот год. Да вон там и фуксию на десктоп - продвигали. В соседней новости. Мало всякой фигни на свете чтоли? > При этом, ЧСХ, сразу же признание что tinkerers будут недовольны потому что контроль тю-тю. Ну так пусть хомячки и юзюют если хотят. А если окажется что хомячкам майки уже винду впарили - ну, окей, этот мир жесток, значит эти ненужные - должны умереть. Ибо кто их аудитория?
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от paulus (ok), 17-Янв-24, 05:26
	> Да вон там и фуксию на десктоп - продвигали. уже не продвигают и даже хоронят в соседней новости :)
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (-), 17-Янв-24, 14:14
	>> Да вон там и фуксию на десктоп - продвигали. > уже не продвигают и даже хоронят в соседней новости :) Ну так я и написал - "продвигали". Мы говорим продвигали, подразумеваем "пытался совершить посадку самолет номер 13". Убунта тоже много чего - продвигала. При том болшая часть этого - уже не с нами. А для меня вот это все - повод убунтой не пользоваться, соответственно. Простите, setup.exe еще в винде заколебали кучей васяноподелок в платформе, где никто ни за что не отвечает - так что если в условном zlib нашли вулн - ну вот попробуйте теперь обновить 50 разномастных программ с ним вообще, удачи! А с пакетником что - поставил 1 либу и весь софт в системе пофиксился. Я нахожу такую разницу в администрировании симпатичной мне, потому и...
	Ответить | Правка | Наверх | Cообщить модератору

	153. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Анонимщик (?), 18-Янв-24, 19:36
	Или не пофиксился, если в новой версии либы совместимость сломали.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (167), 21-Янв-24, 06:52
	> Или не пофиксился, если в новой версии либы совместимость сломали. Я даже и не вспомню таких прецедентов в дистрах ориентированых на продакшн, типа дебианов, убунт LTS и тому подобного. Там просто аккуратно бэкпортируют фикс на уже бывшую в системе версию либы, поводов для отвала - минимум. И по сравнению с вон тем - поддержка системы в секурном состоянии на порядки проще.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (84), 17-Янв-24, 10:28
	Так ты на дкбивне сидишь на древнесофте всегда.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	114. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (114), 17-Янв-24, 14:19
	> Так ты на дкбивне сидишь на древнесофте всегда. С другой стороны я могу предсказуемо поделать свои проекты вместо разгребания ошметков по углам и решения новых, неизвестных мне ранее проблем на ровном месте. А если вы хотите сказать что за пару лет появляется софт который все радикально изменит и я стану намного эффективне... ну и вот что это за софт мог бы быть?
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от WE (?), 17-Янв-24, 09:07
	У меня нет никакого span в centos, пользуйся.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	141. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от BrainFucker (ok), 17-Янв-24, 21:04
	Это как на Андроидах, отключение Google Play, Google Play Services и прочего хлама увеличивает время работы от батареи раза в два.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

4. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+5 +/–
Сообщение от Аноним (4), 16-Янв-24, 23:51
Сначала пять минут на кодинг, а потом Гугл отключает ио ринг к ебеням из-за дыр.  Доверие к этой технологии утеряно. И к автору.
Ответить | Правка | Наверх | Cообщить модератору

	17. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+4 +/–
	Сообщение от Аноним (-), 17-Янв-24, 00:35
	можно пояснительную бригаду для домохозяек?
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Агент Клаус (?), 17-Янв-24, 07:56
	Гуглится как «google отключает io_uring”
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+4 +/–
	Сообщение от Аноним (-), 17-Янв-24, 01:22
	> Сначала пять минут на кодинг, а потом Гугл отключает ио ринг к ебеням из-за дыр. >  Доверие к этой технологии утеряно. И к автору. Как отключат - так и включат, посчитав сколько серверов в проде можно сэкономить. Ибо безопсность конечно хорошо, а бабки считать - еще лучше.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	88. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+1 +/–
	Сообщение от Аноним (84), 17-Янв-24, 10:30
	Они на Андроиде отключили и хромос, лол.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (114), 17-Янв-24, 14:20
	> Они на Андроиде отключили и хромос, лол. Так это тогда вообще не их проблемы - а хомячков которые это купили :). Не у них же тормозит! :)
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+1 +/–
	Сообщение от Аноним (140), 17-Янв-24, 19:46
	Что именно тормозит? Вам точно нужны эти миллионы IOPS на смартфоне? io_uring нужен разве что на серверах, и то не на всех.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–1 +/–
	Сообщение от Аноним (-), 17-Янв-24, 22:59
	> Что именно тормозит? Вам точно нужны эти миллионы IOPS на смартфоне? Ну, правильно, надо ускорять - быстрых, замедлять - медленных, трахаться - за девственность и воевать - за мир. Так победим. При том, кажется, самих себя. > io_uring нужен разве что на серверах, и то не на всех. И правда - зачем вон тем эффективное IO? Все равно вебманки все угробят электроном.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (117), 17-Янв-24, 14:51
	Думаешь, у гугла нет своего RnD, который бы патчил настолько заметные узкие места? Не стоит свои нищенские будни натягивать на современных айти гигантов.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	142. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от BrainFucker (ok), 17-Янв-24, 21:06
	> Думаешь, у гугла нет своего RnD, который бы патчил настолько заметные узкие места? Они толстые места патчить не хотят, чего уж до узких.
	Ответить | Правка | Наверх | Cообщить модератору

5. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
Сообщение от Аноним (13), 16-Янв-24, 23:53
>Идея состоит в том чтобы кэшировать запрос текущего времени в блочной подсистеме, совершаемый при каждой операции ввода/вывода, - поскольку в блочной системе нет ничего, что нуждалось бы в наносекундной точности времени. Доиграются-доускоряются. Будет очередная уязвимость по типу race condition. 6% - это пренебрежимо малая цена за наличие строгого упорядочения.
Ответить | Правка | Наверх | Cообщить модератору

	6. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+2 +/–
	Сообщение от Аноним (13), 16-Янв-24, 23:58
	>Nobody really needs nsec granularity on the timestamp. Отучаемся говорить за всю сеть.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+1 +/–
	Сообщение от name (??), 17-Янв-24, 06:21
	там по идее никто не мешает сделать наносекунды обычным каунтером чтобы не было коллизий
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (84), 17-Янв-24, 10:34
	Может тогда совсем часы реального времени убрать из системы?
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+2 +/–
	Сообщение от Жук (?), 17-Янв-24, 11:44
	Убирайте, я разрешаю
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+1 +/–
	Сообщение от Аноним (56), 17-Янв-24, 06:20
	Послушать тебя, так вообще планировщик ненужен. А чего? Все должно тупо вряд стоять. А очереди к разным процессорам/ядрам это вообще ненужно. Подумаешь прерывания какие-то являющиеся главным тормозом системы, да?
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

10. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–1 +/–
Сообщение от Aliech (ok), 17-Янв-24, 00:15
Шаг 1. Для унификации всего подряд (где-то в районе перехода на 3ю и 4ю версии ядра, чтобы Гуглу проще было с зоопарком ядер на Андройд) делаем возможность подменять системные вызовы ядра на железо-специфичные хуки. Достигается это через разбор кучи условий, в т.ч. через просмотр device tree прямо в рантайме. То есть через лишние накладные расходы к банальному вызову time(). Шаг 2. Думаем, как бы нам кешировать результат системного вызова time(). Ведь системные вызовы такие не быстрые, да.
Ответить | Правка | Наверх | Cообщить модератору

	29. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+4 +/–
	Сообщение от Аноним (-), 17-Янв-24, 01:20
	> Шаг 1. Для унификации всего подряд (где-то в районе перехода на 3ю и 4ю версии ядра, > чтобы Гуглу проще было с зоопарком ядер на Андройд) делаем возможность подменять > системные вызовы ядра на железо-специфичные хуки. Достигается это через разбор кучи > условий, в т.ч. через просмотр device tree прямо в рантайме. Нельзя ли поконкретнее - про что это? File:line в студию? Сорц ядра у меня есть, я проверю. > То есть через лишние накладные расходы к банальному вызову time(). 1) Ядро != юзермод и у него свои внутренности, которыми оно может пользоваться и без всяких сисколлов. И если еще и посмотреть сабжевый код - оно там внутренние фичи ядра и дергало. 2) Смотрение на часы никогда не было какой-то особо простой и дешевой операцией...
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–4 +/–
	Сообщение от Аноньимъ (ok), 17-Янв-24, 01:27
	> 2) Смотрение на часы никогда не было какой-то особо простой и дешевой операцией... Почему?
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+5 +/–
	Сообщение от Аноним (39), 17-Янв-24, 01:47
	Потому что: а) часы - это устройство ввода-вывода, а значит работа с ними - уже недешевое по меркам процессора удовольствие (впрочем, tsc этот момент изрядно оптимизировал по сравнению с HPET и PIC) б) если говорить про юзерспейс, то обращение к часам происходит через отдельный вызов сисколла (а значит привет, переключение контекста). Этот момент, впрочем, тоже в современных системах сильно оптимизирован за счёт vdso. В общем, уже по тому, насколько работу с часами обмазали разными оптимизациями, уже можно понять, насколько это больное место в плане производительности.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от uis (??), 17-Янв-24, 12:06
	TSC раком ставит процессор. А если виртуализация включена - то вообще бяда - происходит вызов в гипервизор.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от n00by (ok), 17-Янв-24, 15:38
	> TSC раком ставит процессор. The RDTSC instruction is not serializing or ordered with other instructions. It does not necessarily wait until all previous instructions have been executed before reading the counter. Similarly, subsequent instructions may begin execution before the RDTSC instruction operation is performed. Осталось понять, кто тут процессор.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+1 +/–
	Сообщение от Аноним (135), 17-Янв-24, 17:32
	> если говорить про юзерспейс, то обращение к часам происходит через отдельный вызов сисколла Нет, если говорить про юзерспейс то обращение к часам происходит через чтение инта из зашаренной страницы памяти.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	43. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+2 +/–
	Сообщение от Аноним (43), 17-Янв-24, 02:24
	>> 2) Смотрение на часы никогда не было какой-то особо простой и дешевой операцией... > Почему? Например, со временем все немного сложнее чем кажется. Особенно с его стабильностью и источником. Возможны разные источники "точного" времени. Их свойства далеко не всегда желаемые на предмет например стабильности. А в целом рюхание всего этого отливается в несколько более сложный процесс чем некоторые себе представляли. И вот у гражданина - 20% времени интересного ему сегмента кода - вот - смотрение на часы оказалось. Это ему и не понравилось. Для юзермода все еще суровее, кернел аж хакает (!!!) юзермод процессы в самом прямом смысле слова - вгружая самым первым в адресное пространство "виртуальный" .so (vDSO) с оверрайдом ряда функций системной либы, в том числе и - вот - смотрение на часы. С более резвой реализацией. В юзермоде это еще более дорогая операция для соответствия поведения "часиков" ожиданиям програмеров и стандартам. Кернел может, вот, заоверлоадить локальной местечковой реализацией, если полагает что умеет это лучше либсы. От хорошей жизни это ессно не делают.
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	137. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноньимъ (ok), 17-Янв-24, 18:33
	Нет, то что следить за временем это не просто совсем с кучей камней - это мне понятно. То есть как ядро свои часы считает это одно, но, смотреть на часы ядра, которые по идее просто инт в памяти - это другое.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–1 +/–
	Сообщение от Аноним (-), 22-Янв-24, 00:21
	> Нет, то что следить за временем это не просто совсем с кучей > камней - это мне понятно. > То есть как ядро свои часы считает это одно, но, смотреть на > часы ядра, которые по идее просто инт в памяти - это другое. Так может сказать только тот кто никогда не пробовал это или что-то отдаленно напоминающее заимплементить сам. Например - это в общем случае не "просто читает int". Если записывает кто-то другой, начинает волновать кеширование и атомарность чтения. Иначе "просто читая int в памяти" однаждо можно читануть нечто странное. При том - это именно фигня из разряда "раз в год и палка стреляет", так что удачи в дебаге. А если вон то учесть - даже одно только это само по себе - уже несколько более дорогая и сложная операция чем "просто чтение int из памяти".
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноньимъ (ok), 22-Янв-24, 10:44
	Нельзя. Запись и чтение атомарные. И вон в тех цп время вообще в отдельном регистре, как и должно быть.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–1 +/–
	Сообщение от n00by (ok), 22-Янв-24, 14:22
	> Нельзя. Запись и чтение атомарные. Пора бы уже начать хоть что-то понимать в теме, прежде чем писать. #ifndef _M_AMD64 /* * @implemented */ VOID NTAPI KeQuerySystemTime(OUT PLARGE_INTEGER CurrentTime) {     /* Loop until we get a perfect match */     for (;;)     {         /* Read the time value */         CurrentTime->HighPart = SharedUserData->SystemTime.High1Time;         CurrentTime->LowPart = SharedUserData->SystemTime.LowPart;         if (CurrentTime->HighPart ==             SharedUserData->SystemTime.High2Time) break;         YieldProcessor();     } }
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноньимъ (ok), 22-Янв-24, 14:42
	> Пора бы уже начать хоть что-то понимать в теме, прежде чем писать. Хоть что-то понимаю. > code Ну и что это за муть без единого комментария? Вы бы лучше процетировали документацию в которой описано почему они делают так, а не иначе.
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от n00by (ok), 22-Янв-24, 14:55
	> Ну и что это за муть без единого комментария? Это понятный каждому системному программисту код с комментарием по существу. > Вы бы лучше > процетировали документацию в которой описано почему они делают так, а не > иначе. Зачем?
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноньимъ (ok), 22-Янв-24, 15:16
	А зачем вы мне что-то вообще пишите? > Это понятный каждому системному программисту код с комментарием по существу. В глаза смотреть, чтение и запись инта атомарные или не атомарные операции?
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от n00by (ok), 23-Янв-24, 08:28
	> А зачем вы мне что-то вообще пишите? Увидел чушь про атомарность чтения. Показал код, решающий проблему. >> Это понятный каждому системному программисту код с комментарием по существу. > В глаза смотреть, чтение и запись инта атомарные или не атомарные операции? Вопросы здесь задаю я. Но смысла спрашивать "при чём тут инт?" не вижу - ответы у меня и так есть.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноньимъ (ok), 22-Янв-24, 14:45
	> Если записывает кто-то другой Никто кроме ядра время устанавливать не должен. И происходить это не каждую минуту и не каждый час должно.
	Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

	37. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–1 +/–
	Сообщение от Аноним (37), 17-Янв-24, 01:42
	> 2) Смотрение на часы никогда не было какой-то особо простой и дешевой операцией... Уже не актуально, так как время можно смотреть через vdso.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	44. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+2 +/–
	Сообщение от Аноним (43), 17-Янв-24, 02:26
	>> 2) Смотрение на часы никогда не было какой-то особо простой и дешевой операцией... > Уже не актуально, так как время можно смотреть через vdso. У того гражданина 20% времени - смотрение на часы оказалось. Вот он и захотел кешировать это дело.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Aliech (ok), 17-Янв-24, 08:11
	> Нельзя ли поконкретнее - про что это? File:line в студию? Сорц ядра у меня есть, я проверю. Да пожалуйста. Ядро 6.1.61, например, файл: drivers/clocksource/arm_arch_timer.c. Отличный образчик обилия костылей, смотрите массив ool_workarounds, начиная со строчки № 437. Но память меня подвела, и всё не настолько критично, как я это запомнил. В рантайме для таймера выбор хуков из device tree методом обхода всего массива в цикле, на данный момент, делается один раз - при инициализации. А потом просто каждый раз дёргается хук, при каждой попытке получения времени. Но некоторые хуки такие красивые... Хук для Allwinner A64, например) Нет, конечно это говорит об качестве чипа, в первую очередь. Но ещё это и образчик того, как и без того не дешёвую операцию обращения к таймеру превратить в нечто совсем ужасающее. Хорошо хоть только для одного чипа. И таких мест, где хуки распиханы по ядру, меняющие поведение и/или увеличивающие расходы на исполнение, много. Что есть следствие централизации разработки ядра. Впрочем я нигде не писал, что идея кешировать обращение к таймеру - совсем не благодатная. Ибо всем понятно, что любые обращения к регистрам и портам - они весьма не бесплатные.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	73. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–1 +/–
	Сообщение от n00by (ok), 17-Янв-24, 09:05
	> смотрите массив ool_workarounds, начиная со строчки № 437. А почему не с #ifdef CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND ? или с     wa = arch_timer_iterate_errata(type, match_fn, arg);     if (!wa)         return;     __wa = __this_cpu_read(timer_unstable_counter_workaround);     if (__wa && wa != __wa)         pr_warn("Can't enable workaround for %s (clashes with %s\n)",             wa->desc, __wa->desc); > В рантайме для таймера выбор хуков из device tree методом > обхода всего массива в цикле, на данный момент, делается один раз > - при инициализации. А потом просто каждый раз дёргается хук, при > каждой попытке получения времени. А зачем вообще, хотя бы гипотетически, может понадобиться на каждый чих разбирать device tree? В данном случае хук выглядит так: #if IS_ENABLED(CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND) ... #define erratum_handler(h)                        \     ({                                \         const struct arch_timer_erratum_workaround *__wa;    \         __wa = __this_cpu_read(timer_unstable_counter_workaround); \         (__wa && __wa->h) ? ({ isb(); __wa->h;}) : arch_timer_##h; \     }) #else #define has_erratum_handler(h)               false #define erratum_handler(h)               (arch_timer_##h) #endif или я что-то недосмотрел?
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Aliech (ok), 17-Янв-24, 10:48
	> или я что-то недосмотрел? Кажется да. Если кратко: массив ool_workarounds (см. drivers/clocksource/arm_arch_timer.c) содержит записи со всеми доступными хуками. Каждая запись содержит в себе данные для сличения с devicetree и идентификаторы функций (содержаться в том же файле). Когда будет производится инициализация таймера, массив ool_workarounds будет прокручен в цикле, и каждая запись будет (по очереди) проверена на предмет соответствия данным из devicetree. И если соответствующая запись будет найдена, то в качестве хуков будут установлены те функции, которые в ней обозначены. Это если очень просто. Я сам не то, чтобы профессиональный разработчик ядра, мог напутать с терминологией. Короче, ребятки приняли devicetree как источник информации о необходимости применения хуков, в т.ч. к системным вызовам. В случае с таймером всё ещё +/- нормально, так как это действо происходит только при инициализации таймера. Но тут стоит посмотреть на код хуков. Вот хук, о котором я писал выше: #define __sun50i_a64_read_reg(reg) ({                    \     u64 _val;                            \     int _retries = 150;                        \                                     \     do {                                \         _val = read_sysreg(reg);                \         _retries--;                        \     } while (((_val + 1) & GENMASK(8, 0)) <= 1 && _retries);    \                                     \     WARN_ON_ONCE(!_retries);                    \     _val;                                \ }) Вот с таким кодом только о производительности таймера и рассуждать. И об предсказуемости времени получения с него корректных результатов.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–1 +/–
	Сообщение от n00by (ok), 17-Янв-24, 15:30
	>[оверквотинг удален] > Кажется да. > Если кратко: массив ool_workarounds (см. drivers/clocksource/arm_arch_timer.c) содержит > записи со всеми доступными хуками. Каждая запись содержит в себе данные > для сличения с devicetree и идентификаторы функций (содержаться в том же > файле). Когда будет производится инициализация таймера, массив ool_workarounds будет > прокручен в цикле, и каждая запись будет (по очереди) проверена на > предмет соответствия данным из devicetree. И если соответствующая запись будет найдена, > то в качестве хуков будут установлены те функции, которые в ней > обозначены. Это если очень просто. Я сам не то, чтобы профессиональный > разработчик ядра, мог напутать с терминологией. В эти дебри я вообще не вникал за ненадобностью. arch_timer_iterate_errata() вызывается 1 раз (код я привёл выше) и, судя по имени функции, результат применяется только для проблемного железа. Для беспроблемного железа (определённая модель телефона, одноплатника и т.п.) можно вообще это всё убрать из ядра конфигом. > Короче, ребятки приняли devicetree как источник информации о необходимости применения > хуков, в т.ч. к системным вызовам. В случае с таймером всё > ещё +/- нормально, так как это действо происходит только при инициализации > таймера. Насколько понимаю, это обычная практика. Точно так же на IA/AMD64 из ACPI, DMI и VID/PID определяется, надо ли применять qurks для другого оборудования. >[оверквотинг удален] >   _retries--;      \ >  } while (((_val + 1) & GENMASK(8, 0)) <= 1 && > _retries); \ >          \ >  WARN_ON_ONCE(!_retries);     \ >  _val;        \ > }) > > Вот с таким кодом только о производительности таймера и рассуждать. И об > предсказуемости времени получения с него корректных результатов. Так если в каком-то частном случае с железом есть проблема, её приходится обходить, что бы хоть как-то работало.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+1 +/–
	Сообщение от Аноним (114), 17-Янв-24, 15:00
	> Отличный образчик обилия костылей, смотрите массив ool_workarounds, Отличный образчик затыкания хардварных ERRATA софтом. И чего? Надо было сказать неудачникам с тем железом - "unsupported HW, факофф, грузиться не будем"? А точно система девелопаемая с таким подходом кому-то нужна? У x86 тоже бывает зиллион приколов. Eg нестабильные частоты TSC или HPET, тот факт что TSC в ряде случаев не тикает если проц idle, и много чего еще. > Но память меня подвела, и всё не настолько критично, как я это запомнил. > В рантайме для таймера выбор хуков из device tree методом обхода всего массива в > цикле, на данный момент, делается один раз - при инициализации. А, ну то-есть признаете что все же попытались меня наесть. При инициализации - может хоть канкан танцевать, в разумных пределах. А вот в крейсерском режиме вон то было бы удивительно. > А потом просто каждый раз дёргается хук, при каждой попытке получения времени. Как по мне нормальная логика, ничего экстраординарного. > Но некоторые хуки такие красивые... Хук для Allwinner A64, например) Нет, конечно > это говорит об качестве чипа, в первую очередь. Но ещё это > и образчик того, как и без того не дешёвую операцию обращения > к таймеру превратить в нечто совсем ужасающее. Было бы лучше совсем это зафейлить, или чего? Я вас не понимаю. Костыли обычно появляются когда хардвар "оставлял желать" и вообще - скажите спасибо что хотя-бы так а не фатальная ошибка и unsupported хардвар. > Что есть следствие централизации разработки ядра. Скорее наоборот - хуки позволяют куче тим разрабатывать под разные чипы, костыля косяки своего чипа как им там надо - не очень импактя соседей. Кернел на арм нынче умеет мульти-бут как раз благодаря DeviceTree и при старте - определит на каком чипе (из набора поддерживаемых) оно взлетает, вкатит нужный хук, и в целом все довольно культурно - насколько кривизна энного чипа позволяла. А один кернель может подымать целый набор разных ARMов, разных вендоров, типа, почти как на x86. Менее оптимально? Более сложный обвес? Ооок! Но это же не просто так. А потому что теперь можно вместо 20 кернелов под 20 железок сделать один - который цепляет их все - и runtime penalty в крейсерском режиме - таки умеренный. Поэтому оно того и стоило. > Впрочем я нигде не писал, что идея кешировать обращение к таймеру - > совсем не благодатная. Ну как бы майнтайнеру блочной подсистемы, наверное, видно - нужны ли его downstream'ам/caller'ам вон те вещи или нет. Он правильный человек в правильном месте, у него есть BigPic в его области. Иначе он бы не был майнтайнером той подсистемы. И если он считает так, очевидно так оно и есть. И врядли кто-то квалифицирован лучше делать такое решение. Если это не так - возникает вопрос "почему он не был майнтайнером подсистемы?".
	Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

	129. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Умею пользоваться поисковиком (?), 17-Янв-24, 15:52
	> А, ну то-есть признаете что все же попытались меня наесть. При инициализации - может хоть канкан танцевать, в разумных пределах. А вот в крейсерском режиме вон то было бы удивительно. Вас? Я таки признал, что ошибся, в части "дёргает devicetree при каждом вызове". Дело давно было, когда я туда заглядывал последний раз. Так что это я публично глупость спорол, предварительно не перепроверив. Зачем вы это выворачиваете осмысленной попыткой обманут конкретно вас? > Кернел на арм нынче умеет мульти-бут как раз благодаря DeviceTree и при старте - определит на каком чипе (из набора поддерживаемых) оно взлетает, вкатит нужный хук, и в целом все довольно культурно - насколько кривизна энного чипа позволяла. А один кернель может подымать целый набор разных ARMов, разных вендоров, типа, почти как на x86. Вы слишком очевидны, Капитан! Но это, я разве не писал о том же? Вот выше же было: > И таких мест, где хуки распиханы по ядру, меняющие поведение и/или увеличивающие расходы на исполнение, много. Что есть следствие централизации разработки ядра. И да, я застал те "волшебные времена", когда какой-нибудь TI мог для своих OMAP'ов выкатить пару релизов ядер, а потом забить. И гуляйте. Но у всего есть всегда две стороны. Теперь "мы" выбрали одно ядро, которое должно запускаться везде. Чтобы больше не оказываться в ситуации, когда "прилип" к 2.6.18, а в mainline уже 3.x. Но... больше нет возможности иметь реально оптимизированные под железо ядра. Потому что такой глубины доработки не подразумевает общее ядро. > Скорее наоборот - хуки позволяют куче тим разрабатывать под разные чипы, костыля косяки своего чипа как им там надо - не очень импактя соседей. > Менее оптимально? Более сложный обвес? Ооок! Но это же не просто так. А потому что теперь можно вместо 20 кернелов под 20 железок сделать один - который цепляет их все - и runtime penalty в крейсерском режиме - таки умеренный. Поэтому оно того и стоило. Так вот. Mainline на A64 крутился нормально некоторое время, пока не подвезли немножечко нового функционала для arm64. Который как-то косвенно повлиял на проявление этой ошибки. Стали ли откатывать что-то? Нет. Завезли несколько костылей, для конкретной errata. И плевать, насколько убогие эти костыли. А поправить это качественно, "не импактя соседей" не получается, по всей вероятности. > Ну как бы майнтайнеру блочной подсистемы, наверное, видно - нужны ли его downstream'ам/caller'ам вон те вещи или нет. Он правильный человек в правильном месте, у него есть BigPic в его области. Иначе он бы не был майнтайнером той подсистемы. И если он считает так, очевидно так оно и есть. И врядли кто-то квалифицирован лучше делать такое решение. Если это не так - возникает вопрос "почему он не был майнтайнером подсистемы?". Ну так я нигде не писал, что считаю его выбор не правильным. Настоятельно рекомендую перечитать эту фразу ещё пару раз: > Впрочем я нигде не писал, что идея кешировать обращение к таймеру - совсем не благодатная.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–1 +/–
	Сообщение от n00by (ok), 17-Янв-24, 16:40
	>> А, ну то-есть признаете что все же попытались меня наесть. При инициализации - может хоть канкан танцевать, в разумных пределах. А вот в крейсерском режиме вон то было бы удивительно. > Вас? Я таки признал, что ошибся, в части "дёргает devicetree при каждом > вызове". Дело давно было, когда я туда заглядывал последний раз. Так > что это я публично глупость спорол, предварительно не перепроверив. Зачем вы > это выворачиваете осмысленной попыткой обманут конкретно вас? Сам по себе факт, что тут признали ошибку открыто - большая редкость. Потому тот Аноним про это и написал. Плюс, у него такой стиль, что бы отличаться от других Анонимов, любящих говорить от имени "всех". Вот их "наесть" не получилось бы при всём желании - они всё равно ничего не поняли.
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–1 +/–
	Сообщение от Аноним (-), 18-Янв-24, 00:14
	> Вас? Я таки признал, что ошибся, в части "дёргает devicetree при каждом вызове". "В том числе и меня" - технически некорректным утверждением. Мне настолько жирный косяк показался подозрительным для майнлайна, обычно народ там понимает что делает и фирма ARM врядли позволила бы саботировать их чипы. > Дело давно было, когда я туда заглядывал последний раз. Так > что это я публично глупость спорол, предварительно не перепроверив. И это отлично. Не каждый сможет признать свою ошибку. Вы для меня стали на голову выше многих местных слабаков, неспособных на такое. > Зачем вы это выворачиваете осмысленной попыткой обманут конкретно вас? Обмануть ALL - хуже чем (попытаться) обмануть меня. Я привык смотреть на мир скептично, проверять input, нужное мне знание будет сэмплировано с нескольких точек и перепроверено, маневр скорее всего не удастся. ...а вот если какие-то бакланы читанут резкое утверждение и пойдут ретранслировать этот левак - было бы досадно. В общем все хорошо, что хорошо кончается. > Вы слишком очевидны, Капитан! Бывает, блин. > И да, я застал те "волшебные времена", когда какой-нибудь TI мог для > своих OMAP'ов выкатить пару релизов ядер, а потом забить. И гуляйте. Угумс, и такое бывало. Потом куча "machines" в arch/arm и проч. А ядро могло только 1 из цеплять. Потом ЭТО всем надоело и сделали DTB - "виртуальный плагнплей". Ядру так то пофиг какие драйверы грузить. > нет возможности иметь реально оптимизированные под железо ядра. Потому что такой > глубины доработки не подразумевает общее ядро. Тем не менее... 1) Оверхед сам по себе обычно умеренный. Даже в том хуке, разовая инициализация и назначение энной функции само по себе довольно эффективно. 2) Ненужные фичи можно и не собирать как правило. Даже вон тот воркэраунд вроде ifdef'нут. 3) Premature optimization is a root of all evil (c). Это именно тот случай! Глядя на "machines" бардак с всем этим. А так у меня есть например мои кернелы "для некоторых sunxi". А какую-нибудь тегру или квалком они не умеют. Потому что я с вот этими дело имею. Кернел окучивает некий выводох схожих железок, и хорош. > этой ошибки. Стали ли откатывать что-то? Нет. Завезли несколько костылей, для > конкретной errata. И плевать, насколько убогие эти костыли. А поправить это > качественно, "не импактя соседей" не получается, по всей вероятности. В случае ERRATA - p0 сделать так чтобы работало и не долбалось багом. И то что он не вылезал до этого - а это точно верно? Для всех случаев? А то бывает что - лезет, но редко. Чинить надо root cause а не слепо откатывать изменения подхайлайтившие проблему. > Ну так я нигде не писал, что считаю его выбор не правильным. > Настоятельно рекомендую перечитать эту фразу ещё пару раз: >> Впрочем я нигде не писал, что идея кешировать обращение к таймеру - совсем не благодатная. Ну вот и отлично, консенсус. А кернел так то не выбит в камне. Если кому-то зачем-то станет надо - еще что-то придумают. Они всегда так делают.
	Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

	149. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+1 +/–
	Сообщение от Aliech (ok), 18-Янв-24, 02:40
	> Угумс, и такое бывало. Потом куча "machines" в arch/arm и проч. А ядро могло только 1 из цеплять. Потом ЭТО всем надоело и сделали DTB - "виртуальный плагнплей". Ядру так то пофиг какие драйверы грузить. И вот мы находимся в моменте, когда и dtb вроде бы внедрили, а в прод по-прежнему собираю несколько ядер. Потому что некоторые патчи, специфичные для rockchip, например, портят производительность/меняют поведения ядра, если с ними запускаться на sunxi, например. И появляется вопрос: а в полной ли мере сейчас оправдана идея одного ядра? Или всё-таки несколько вендоро-специфичных? // конечно это лучше рака, когда каждая плата требовала ядра Тут скорее другой вопрос: а сможет ли комьюнити унести на своих плечах форк под платформу. Ну вот тот же sunxi. Такой глубины форк, чтобы даже на H6 pci-e заработал корректно. На мой взгляд - нет. Потому что вендоры сваливают железо, возможно ещё и SDK, а потом бодро умывают руки. А ведь ядро становится всё запутанней, релиз за релизом. И получается, что не > В случае ERRATA - p0 сделать так чтобы работало и не долбалось багом. а "на более качественное решение нет ресурсов". Так что одно ядро и dtb+хуки - это тупо надежда, что на купленных железках можно будет запустить свежее ядро. Но придётся смириться с обрезанным функционалом и прочей невозможностью адаптации. И вот мы не то, чтобы совсем ушли из той ситуации 2008-2009 годов, обозначенной выше. > А так у меня есть например мои кернелы "для некоторых sunxi". А какую-нибудь тегру или квалком они не умеют. Потому что я с вот этими дело имею. Кернел окучивает некий выводох схожих железок, и хорош. Ну я выше уже написал об аналогичной ситуации. > В случае ERRATA - p0 сделать так чтобы работало и не долбалось багом. И то что он не вылезал до этого - а это точно верно? Для всех случаев? А то бывает что - лезет, но редко. Чинить надо root cause а не слепо откатывать изменения подхайлайтившие проблему. Год+ до какого-то изменения, которое я упустил. Полёт нормальный был. Но однажды началось... Я тогда старался пользоваться ядром от дистрибутива, одним, везде... Ведь dtb, унификация и вот это всё. И вот ничто не предвещает беды... и после обновления системы на пяти платах плавающая проблема с улетающим в будущее таймером. Подарочек, блин. Но это был полезный опыт. Так и в сортах хуков разбираться начинаешь, и к идее о необходимости собственной сборки ядер неотвратимо приходишь.
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–1 +/–
	Сообщение от Аноним (-), 22-Янв-24, 03:26
	> И вот мы находимся в моменте, когда и dtb вроде бы внедрили, > а в прод по-прежнему собираю несколько ядер. Потому что некоторые патчи, > специфичные для rockchip, например, портят производительность/меняют поведения ядра, Я использую майнлайн ядра. Если проблема мешает жить, я стараюсь чтобы ее устранили в майнлайн. И вроде рокчип норм поддерживается в майнлайн, сам вендор это делает. Что за патчи и зачем? > если с ними запускаться на sunxi, например. И появляется вопрос: а > в полной ли мере сейчас оправдана идея одного ядра? Меня устраивает. Если кому надо дожимать последние проценты железки - он вероятно с выбором платформы облажался на старте. Это фейл другого порядка. > Или всё-таки несколько вендоро-специфичных? > // конечно это лучше рака, когда каждая плата требовала ядра Для меня вон то - юзабельно вполне. И выбирая между майнтенансом зоо и несколько % перфоманса, пардон, но я выбираю платформы под задачу с запасом и плюс-минус несколько % не жмет. > Тут скорее другой вопрос: а сможет ли комьюнити унести на своих плечах > форк под платформу. Ну вот тот же sunxi. Вопрос другой: "а стоит ли оно того?" Premature optimization is a root of all evil (c). > Такой глубины форк, чтобы даже на H6 pci-e заработал корректно. На мой взгляд - нет. Поэтому я не буду закладываться на PCIe в H6. Или если ооочнадо, есть финт через гипервизор без патча майнлайна. Но реально это кривой pcie. > потом бодро умывают руки. А ведь ядро становится всё запутанней, релиз за релизом. Поэтому мое будущее майнлайн, с 0 патчей относительно него. Норм подход решить проблему в майнлайн и построить перфекционизм, имхо. > "на более качественное решение нет ресурсов". Разработка софта это сложный многофакторный процесс, а мир не идеален. С этим придется жить. Я люблю оптимизации и использование фич железа, но если цена за это слишком высока с другой стороны, для меня это соображение может перевесить. Мне не надо последние 5% перфоманса ЛЮБОЙ ценой. И pcie - тоже. > Так что одно ядро и dtb+хуки - это тупо надежда, что на > купленных железках можно будет запустить свежее ядро. Это - унификация. И да, при этом придется немного слить оптимизации. Перфекционизм надо держать под контролем, неспособность это сделать воздается дурными проблемами. > Но придётся смириться с обрезанным функционалом и прочей невозможностью адаптации. > И вот мы не то, чтобы совсем ушли из той ситуации 2008-2009 годов, обозначенной выше. Для меня DTB/NONDTB это очень принципиальная граница водораздела. С DTB я готов к будущему и могу переиграть ряд решений, унифицировать, ... без - упс. Более того с DTB можно изменить лэйаут системы опосля, ну там датчик на i2c зацепив и прописав в dtb, и система увидит его - обычными дровами этого сенсора. "Почти plugnplay" для того что его никогда не умело. > Ну я выше уже написал об аналогичной ситуации. В этом смысле я бы старался во первых получить 0 размер патча vs майнлайн (кроме вон того), а во вторых - выбрал бы между перфомансом и затратами на майнтенанс исходя из того что мне актуальнее. У меня довольно много типов девайсов развелось и я вполне могу выбрать и более простой майнтенанс, ибо никогда не беру платформы впритых, и ориентируюсь на майнлайн как есть. > dtb, унификация и вот это всё. И вот ничто не предвещает беды... и после обновления > системы на пяти платах плавающая проблема с улетающим в будущее таймером. Подарочек, блин. Я гоняю некие квалификационные тесты на интересных мне железках в -rc обычно подарочки ловятся на подлете, а при нужде и бисектятся и причастные пинаются. Но в ряде случаев можно и дефернуть апдейты и проскипать версию ядра. Реально pressing поводов ядро апдейтить разве что вулны, при этом я могу откосплеить на минимуме майнтайнера и пропатчить вулн в том что там было - а более плотно заняться по мере возможностей. > Но это был полезный опыт. Так и в сортах хуков разбираться начинаешь, > и к идее о необходимости собственной сборки ядер неотвратимо приходишь. Я конечно не юзаю на ARM дистровые ядра. Хотя-бы потому что мне с initrd зачастую лениво возиться. Это тоже некий tradeoff и имеет свои плюсы и минусы. Кроме того я порой весьма радикально переигрываю их конфиг, с оптимизацией и дефолтами на именно эмбед и то что там актуально. Скажем авторебут при панике по бырому, etc и ряд иных вещей.
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–1 +/–
	Сообщение от n00by (ok), 18-Янв-24, 19:36
	Мне одно не вполне понятно, почему эту штука упорно называется хуком, а не колбеком, например. В моём понимании, хук, это когда функциональность отсутствует и её прикручивают чем-то типа синей изоленты. По запросу linux+kernel+hook первое попавшееся "At the time, it was a hot patching technology for Linux" https://www.programmersought.com/article/70331869018/ что я и ожидал увидеть. Через призму этой неточности остальной текст не вызвал удивления.
	Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

	154. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–1 +/–
	Сообщение от n00by (ok), 18-Янв-24, 19:52
	> "At the time, it was a hot patching technology for > Linux" https://www.programmersought.com/article/70331869018/ что я и ожидал увидеть. ммм... это тоже вполне ожидаемо для первого попавшегося. inline unsigned long disable_wp(void) {     unsigned long cr0;     preempt_disable();     barrier();     cr0 = read_cr0();     write_cr0(cr0 & ~X86_CR0_WP);     return cr0; }
	Ответить | Правка | Наверх | Cообщить модератору

11. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
Сообщение от Аноним (13), 17-Янв-24, 00:18
>Querying the current time is the most costly thing we do in the block layer nehalem: rtdsc throughput^-1: 24, портов не занимает. Ну в принципе довольно долго, да, так как умножение - 1-2. Плюс ещё по 6 тактов на освобождение нужных регистгов. Но не настолько долго, чтобы ради производительности это упразднять.
Ответить | Правка | Наверх | Cообщить модератору

	28. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (-), 17-Янв-24, 01:16
	> Ну в принципе довольно долго, да, так как умножение - 1-2. Плюс ещё по 6 тактов > на освобождение нужных регистгов. Но не настолько долго, чтобы ради производительности > это упразднять. Он просто посмотрел на это в "perf top" и увидел что ему не нравится тот процент. Так просто и банально. Да, в линухе есть довольно продвинутый профайлинг. Уже давно.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+1 +/–
	Сообщение от n00by (ok), 17-Янв-24, 09:13
	IA SDM Vol 3b, 17.17.1 Invariant TSC The time stamp counter in newer processors may support an enhancement, referred to as invariant TSC. Processor’s support for invariant TSC is indicated by CPUID.80000007H:EDX[8]. The invariant TSC will run at a constant rate in all ACPI P-, C-. and T-states. This is the architectural behavior moving forward. On processors with invariant TSC support, the OS may use the TSC for wall clock timer services (instead of ACPI or HPET timers). TSC reads are much more efficient and do not incur the overhead associated with a ring transition or access to a platform resource.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

18. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
Сообщение от Аноним (13), 17-Янв-24, 00:36
Объясните мне, зачем взаимодействие с io_uring вообще идёт через сисколы? Для настройки и заверления зачем сискол нужен понятно. Но зачем нужен io_uring_enter? Ядро же само в отдельном потоке на отдельном ядре может проверить кольцевой буфер, без всякого сискола в потоке приложения. Ядро и так переключает потоки и процессы по таймеру и событиям, может заодно и буффер проверять. В результате при таком механизме вообще никаких доп. задержек на сисколы от приложения. Зачем нужен этот сисколл?
Ответить | Правка | Наверх | Cообщить модератору

	19. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (19), 17-Янв-24, 00:42
	Что-то у меня ощущение, что будет лагать. А как сообщить с nohz, когда прерывания не тикают?
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (39), 17-Янв-24, 01:51
	С nohz прерывания на процессорном ядре не тикают только если runnable таска только одна.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+1 +/–
	Сообщение от Аноним (96), 17-Янв-24, 11:19
	В спинлоке что-ли ядро должно мониторить кольцевой буфер?
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	105. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (105), 17-Янв-24, 12:48
	Варианты возможны. Можно и в спинлоке (как оказалось, на новых процах он эффективный). А можно и подождать, пока контекст естественным образом переключится на ядро: сетевой пакет там прийдёт, или пользователь мышью двинет, или таймер вытесняющей многозадачности сработает... Должно решаться адаптивно. Если поток событий i/o через io_uring высок, то выделить ядра cpu только под ядерный код. Если поток небольшой - то ждать естественного переключения на ядро.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (117), 17-Янв-24, 15:14
	Инструкцию пробовал читать? Ядро переключает потоки через прерывание, которое потом обрабатывается на одном из ядер вытесняя обычные приложения. Ядро не может здесь делать ничего тяжёлого. io_uring может использоваться в разных вариантах, в частности можно запустить обработку сразу в отдельном ядерном потоке и тогда io_uring_enter(...) нужен для управления потоком и синхронизации. А можно и не запускать. В остальных случаях io_uring_enter(...) для приложения работает как более эффективный poll-ер с гранулярной настройкой порога срабатывания, позволяющий снижать кол-во сисколов при прочих равных.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

30. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–6 +/–
Сообщение от Аноньимъ (ok), 17-Янв-24, 01:21
> поскольку в блочной системе нет ничего, что нуждалось бы в наносекундной точности времени. О сколько открытий чудных ждёт в будущем. Ну хотя, за 5 минут добавили, за 5 и убрать можно. > как оказалось, реализация идеи заняла всего 5 минут. Дурное дело не хитрое. А собственно почему, чтение времени вообще хоть какую-то задержку несёт? Это-же блин должно быть доступное всем подсистемам значение для чтения, писать и читать можно одновременно. И если я верно помню, у каждого ядра ЦП свой таймер, то есть NUMA локальность соблюдается. Или они каждый раз для каждой программы делают прерывание чтобы время узнать? Да ну не может быть такого.
Ответить | Правка | Наверх | Cообщить модератору

47. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
Сообщение от Аноним как всегда (?), 17-Янв-24, 03:11
Монтирую диски на своем локалхостике как noatime,nodiratime,commit=60 уже лет 10 как как появились ssd диски
Ответить | Правка | Наверх | Cообщить модератору

	52. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (52), 17-Янв-24, 05:36
	И получаешь увеличение скорости операций на 2%, которую на глаз даже заметить не можешь)
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–1 +/–
	Сообщение от Аноним (84), 17-Янв-24, 10:21
	А на самом деле он это добавил чтобы сократить число записей якобы ссд так дольше живут.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–1 +/–
	Сообщение от Аноним (52), 17-Янв-24, 12:52
	SSD - это расходник. Сколько он своими твиками прибавит к работе SSD? Неделю к трем, пяти годам? )))
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+2 +/–
	Сообщение от Аноним (19), 17-Янв-24, 12:54
	Нормальные ссд примерно вечные кстати, ты просто зажрался.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (52), 17-Янв-24, 13:17
	Действительно, у меня их много и разных фирм: Samsung, Kingston, WD. Правда большая часть уже в ящике без дела лежит, хоть и рабочие ещё.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (114), 17-Янв-24, 15:22
	> И получаешь увеличение скорости операций на 2%, которую на глаз даже заметить не можешь) Из капель собираются реки. Вот так 2% тут, 6% там, goto 1, ... и так вот раз, смотришь, вот тут мелкая, аккуратная, супершустрая система. А вон там - спагетти монстр где вся операционка работает как приложуха на электроне. Т.е. тормозит всем и везде.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	132. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (52), 17-Янв-24, 16:31
	Если заняться нечем, то можно заняться оптимизацией ради оптимизации. Твой ручеёк даст немного скорости (было десять минут на работу, стало девять минут и тридцать секунд), зато потратил время, а мог бы ... Хотя особо упоротые (я тоже такое был лет 15 назад) собирают Gentoo и тратят драгоценное время на оптимизацию на своём локалхосте. Единственное, где я допускаю оптимизацию - это сервера, для которых важно все: энергопотребление, скорость и так далее. Для локалхоста это излишнее, разницу на глаз не увидишь, а если увидешь, то спокойно поменяешь железо, которое уже не первой свежести (пять лет и более).
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (-), 18-Янв-24, 00:31
	> Если заняться нечем, то можно заняться оптимизацией ради оптимизации. А вы часто отыгрываете 6% перфоманса за 5 минут, чтобы быковать тут? :) К тому же в metadata intensive loads вон тот совет может и в пару раз отыграть, хренли. Колупать все метаданные во имя записи времени доступа с эвон какой точностью, при том что 95% вероятности что их возможно и смотреть то никто никогда не будет - весьма спорное занятие by design. > Твой ручеёк даст немного скорости (было десять минут на работу, стало девять > минут и тридцать секунд), зато потратил время, И вот так вот тик-так, тик-так, девять минут станут восемь. Потом семь. А вот мы уже и за 5 минут завершаем. И вообще - да что там больше 2 минут делать то?! А втыкали на это по 10 минут как болваны. Просто потому что "system is thrashing" в руках питекантропа. > а мог бы ... Мог бы что? За время вписывания вон того совета в допустим в fstab? За это время я, даже, имхо, посц@ть бы не успел сходить. Сколько это вписать в fstab? Секунд 20? Это ужасные затраты времени. > Хотя особо упоротые (я тоже такое был лет 15 назад) собирают Gentoo > и тратят драгоценное время на оптимизацию на своём локалхосте. Есть два полюса - чрезмерные оптимизаторы с 1 стороны, уг на электроне с другой, когда лопатник с 6-амперным аком за полдня сдувается, норовя обжечь руки. > Единственное, где я допускаю оптимизацию - это сервера, для которых важно все: > энергопотребление, скорость и так далее. А на десктопе мне зачем бы наслаждаться тормозами? Кроме всего прочего я еще и как тот анон люблю качественный софт и быстрые компы. Шустрой системой пользоваться еще и просто приятно. А ты можешь ждать апдейтов времен доступа и чего там еще - если тебе оно за каким-то хрееном надо. А я например кернел рекомпилю, это может ворочать до 250К файлов. И несколько микросекунд на файл может стать минутами при таком раскладе. Оно мне надо? :) > Для локалхоста это излишнее, разницу на глаз не увидишь, а если увидешь, > то спокойно поменяешь железо, которое уже не первой свежести (пять лет и более). Да, конечно, и смена железа - это бесплатно по деньгам (на из заработок время, видимо не тратится?) - и я вот сразу телепортируюсь на новое железо и оно немедленно будет готово к работе с удобным мне окружением? Или таки на сетап этого придется тоже время просажить? Там, кстати, те советы станут еще актуальнее. Потому что чем быстрее хардвар тем больше занимает оверхед на всякие внутренние служебные вещи, типа, вот, апдейта каких там очень нужных времен и проч. И чего это я заплатив за хардвар должен обуть себя на его настоящий перфоманс - тормознув ненужными операциями? Я маклауд чтоли ждать ненужные мне операции?
	Ответить | Правка | Наверх | Cообщить модератору

51. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
Сообщение от Аноним (51), 17-Янв-24, 05:28
Маяться идеей 5 лет - нормально. Поработать 5 минут - ну его нафиг, лень. Типичный гений программирования, уже наверное десятки таких видел, считают, раз умный, работать ниже достоинства.
Ответить | Правка | Наверх | Cообщить модератору

	55. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+7 +/–
	Сообщение от Гений (??), 17-Янв-24, 06:20
	Всегда так делаю
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (87), 17-Янв-24, 10:29
	Просто никто идею не купил и вот выложил как и корпы выкидывают в помойку для всех разное ненужно.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

54. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
Сообщение от Аноним (54), 17-Янв-24, 05:49
Тут ускорили, там ускорили... Флешмоб?
Ответить | Правка | Наверх | Cообщить модератору

	62. Скрыто модератором	+/–
	Сообщение от Аноним (-), 17-Янв-24, 07:10
	Да!
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (67), 17-Янв-24, 07:51
	что только не сделаешь, лишь бы не копать картошку
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	94. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
	Сообщение от Аноним (94), 17-Янв-24, 11:13
	Что-то новостей про Python давно не было...
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

64. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
Сообщение от Аноним (64), 17-Янв-24, 07:23
если увеличить очередь- iops ещё вырастет
Ответить | Правка | Наверх | Cообщить модератору

66. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
Сообщение от Аноним (66), 17-Янв-24, 07:47
5 лет исследований, 5 минут кодинга,а про время потраченное на отладку ни слова.
Ответить | Правка | Наверх | Cообщить модератору

	81. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+1 +/–
	Сообщение от Аноним (84), 17-Янв-24, 10:19
	Он ничего не исследовал 5 лет, лол.
	Ответить | Правка | Наверх | Cообщить модератору

77. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
Сообщение от Аноним (77), 17-Янв-24, 09:18
Часто мне вообще нет дела до timestamp в файлах. Если бы кто-то сделал макрос в ядре, который и вовсе заменяет все временные метки какой-либо инкрментирующейся на 1 при каждом доступе переменной - в значительном числе изделий я этого бы даже не заметил.
Ответить | Правка | Наверх | Cообщить модератору

	127. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+2 +/–
	Сообщение от Аноним (117), 17-Янв-24, 15:35
	Так на тебя всем накласть, это важно для приложений. И здесь речь о другом
	Ответить | Правка | Наверх | Cообщить модератору

79. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
Сообщение от Аноним (84), 17-Янв-24, 10:18
Может вообще время не записывать нафиг его. Будет никому неведомо в никаком году.
Ответить | Правка | Наверх | Cообщить модератору

80. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+1 +/–
Сообщение от Аноним (80), 17-Янв-24, 10:19
а если добавить в процеессор регистр времени? дополнительный пин такта времени на корпусе процессора по которому регистр будет увеличиваться. начальное значение выставлять на старте из биос ну тоесть в процессор добавить часы часы в биос тоже оставить чтобы не делать обратную синхронизацию в биос из процессора а чтобы не было расхождения часы в биос и часы в процессоре на одной шине такта времени. добавить ассемблерную комманду чтения регистра времени. тогда можно будет сделать автоматическую замену всего кода обращения к текущему времени на эту комманду наверное так можно сделать. чисто технически вроде не сложно.
Ответить | Правка | Наверх | Cообщить модератору

	123. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+2 +/–
	Сообщение от Аноним (114), 17-Янв-24, 15:18
	> а если добавить в процеессор регистр времени? У этого анонима определенно воруют идеи. При том некоторые, кажется, используют для этого машину времени. > дополнительный пин такта времени на корпусе процессора по которому регистр будет > увеличиваться. TSC изобрели довольно много лет назад. Но с ним и его поведением есть определенные нюансы. > часы в биос тоже оставить чтобы не делать обратную синхронизацию в биос Linux работает на чертовой куче платформ где вообще нет никакого биоса... поэтому в терминах linux это называется hwclock или rtc - и вон то в биосе лишь 1 из частных реализаций. Как правило ядерное время инициализируется из RTC при загрузке, а при шатдауне (и иногда при работе изредка) - записывается обратно. Потому что ядерное время может быть точнее. Скажем, если система по NTP время синхрит. Но времена разные бывают. RTC это не про наносекундную точность, оно обеспечивается скоростными таймерами, TSC и проч - и платформозависимо. > наверное так можно сделать. чисто технически вроде не сложно. Чтобы рассуждать по теме надо в ней хоть что-то понимать для начала...
	Ответить | Правка | Наверх | Cообщить модератору

91. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
Сообщение от Аноним (91), 17-Янв-24, 10:50
>не сделал это еще 5 лет назад, когда идея впервые пришла ему в голову >реализация идеи заняла всего 5 минут и вот так на самом деле везде и всё!
Ответить | Правка | Наверх | Cообщить модератору

97. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
Сообщение от Пряник (?), 17-Янв-24, 11:24
Интересная идея. Но лучше ввести новый тип времени, как было с relaytime. Некоторым программам может быть нужна наноточность. Зачем ограничивать?
Ответить | Правка | Наверх | Cообщить модератору

131. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
Сообщение от Аноним (131), 17-Янв-24, 16:23
Хорошая новость. Ничего не сломали.
Ответить | Правка | Наверх | Cообщить модератору

	139. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	–1 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 17-Янв-24, 19:08
	> Ничего не сломали Они просто об этом не знают. А баги и уязвимости будут у тебя (да, у тебя) аноним.
	Ответить | Правка | Наверх | Cообщить модератору

138. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+1 +/–
Сообщение от Вы забыли заполнить поле Name (?), 17-Янв-24, 19:07
> потратив всего 5 минут на кодинг Херакс-херакс и в прод? Тесты для слабаков. > создатель io_uring А ну тогда понятно. Сколько там дней без уязвимостей?
Ответить | Правка | Наверх | Cообщить модератору

145. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
Сообщение от Дед банан (?), 17-Янв-24, 23:17
6% относительно чего ?
Ответить | Правка | Наверх | Cообщить модератору

146. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
Сообщение от Аноним (146), 18-Янв-24, 00:06
Закешировали время на час?
Ответить | Правка | Наверх | Cообщить модератору

178. "Увеличение скорости ввода/вывода на 6% в Linux, благодаря кэ..."	+/–
Сообщение от Quad Romb (ok), 09-Мрт-24, 17:03
"Кэширование запросов времени"... Лихой парень! Такой запросто закэширует первого пользователя для аутентификации всех остальных в какой-нибудь очереди. Но, за что ему спасибо - сам честно признался в том, что творит.
Ответить | Правка | Наверх | Cообщить модератору

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

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