The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Релиз ядра Linux 6.2, opennews (??), 20-Фев-23, (0) [смотреть все]

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


8. "Релиз ядра Linux 6.2"  +1 +/
Сообщение от InuYasha (??), 20-Фев-23, 13:34 
> также осуществляется замедление выполнения процесса, вызвавшего блокировку, чтобы сохранить производительность остальной системы.

Это интересно. Ещё бы для I/O такое запилили когда одно копирование с харда на USB может нагнуть любую элитную машину на полчаса.

Ответить | Правка | Наверх | Cообщить модератору

14. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (14), 20-Фев-23, 14:01 
> блокировку, чтобы сохранить производительность остальной системы
> Это интересно. Ещё бы для I/O такое запилили

лучше бы запилили zero copy для IO

Ответить | Правка | Наверх | Cообщить модератору

175. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (175), 20-Фев-23, 22:29 
а тебе кто мешает?
Ответить | Правка | Наверх | Cообщить модератору

198. "Релиз ядра Linux 6.2"  +1 +/
Сообщение от Аноним (-), 20-Фев-23, 23:49 
> лучше бы запилили zero copy для IO

Так запилили же - io_uring это называется. Another happy customer leaves building... :)))

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

341. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (14), 22-Фев-23, 13:51 
> Так запилили же - io_uring это называется.

это не совсем то, надо чтобы контроллеры дисков копировали друг другу данные без использования CPU - он должен только координировать что и куда копировать в соответствии с ФС. Это широко используется для графики и видео (dmabuf), неплохо бы расширить и на другие аппаратные контроллеры.

Ответить | Правка | Наверх | Cообщить модератору

352. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (-), 22-Фев-23, 20:35 
> это не совсем то,

Вы хотели zeron copy, оно как раз и не копирует ничего. Шарит буфер между ядром и юзермодом, копировать как раз не требуется.

> надо чтобы контроллеры дисков копировали друг другу данные
> без использования CPU - он должен только координировать

Поздравляю, вы только что изобрели DMA и очереди команд. Проблема в том что вы не первый кто до этого допер.

> что и куда копировать в соответствии с ФС.

Ну так ФС кидает свои пожелания к блочному уровню, вон тот слой транслирует это в команды накопителя. И это все в современном железе основательно подперто хардварными автоматами, DMA, очередями команд и всем таким.

> Это широко используется для графики и видео (dmabuf), неплохо бы расширить
> и на другие аппаратные контроллеры.

Дисковые контроллеры несколько глупей видеокарт и не программируются "с другой стороны" толком. Тем не менее современные штуки на PCIe так то могут и DMA транзакции фигачить. Правда, хотели ли вы DMA транзакцию с вон того SSD себе по памяти кернела - ну такой себе отдельный вопрос... возьмет да и пропатчит кернель, если IOMMU не поймает это.

Ответить | Правка | Наверх | Cообщить модератору

366. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (14), 22-Фев-23, 22:42 
> Дисковые контроллеры несколько глупей видеокарт и не программируются "с другой стороны" толком.

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

https://lore.kernel.org/lkml/20230220105336.3810-7-nj.shetty.../

> Тем не менее современные штуки на PCIe так то могут и DMA транзакции фигачить. Правда, хотели ли вы DMA транзакцию с вон того SSD себе по памяти кернела - ну такой себе отдельный вопрос

для AMD это реализовано в ядре

https://www.phoronix.com/news/Linux-5.2-AMD-Zen-P2P-DMA

Ответить | Правка | Наверх | Cообщить модератору

425. "Релиз ядра Linux 6.2"  +/
Сообщение от adolfus (ok), 05-Мрт-23, 01:25 
SATA не поддерживает обмен данными между двумя устройствами. Купи себе систему с SAS и будет тебе счастье.
Ответить | Правка | К родителю #341 | Наверх | Cообщить модератору

20. "Релиз ядра Linux 6.2"  +19 +/
Сообщение от Аноним (20), 20-Фев-23, 14:10 
Им бы для начала вообще копирование на USB исправить, чтобы система не считала, что перенос в буфер == завершение копирования. Но этот столетний баг слишком мелкий, чтобы с ним возиться, видимо.
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

35. "Релиз ядра Linux 6.2"  +1 +/
Сообщение от Аноним (102), 20-Фев-23, 14:40 
А это баг, а не фича?
Ответить | Правка | Наверх | Cообщить модератору

199. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (-), 20-Фев-23, 23:50 
> А это баг, а не фича?

Для растяп забывающий unmount+eject флехи - еще какая, но она есть и в винде, макоси и прочих андроидах даже. Потому что если писать совсем без буфера это может оказаться медленно и печально.

Ответить | Правка | Наверх | Cообщить модератору

282. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (282), 21-Фев-23, 12:00 
>Потому что если писать совсем без буфера это может оказаться медленно и печально

Т.е.вы хотите сказать что волшебный буфер способен разогнать мою флешку до почти ssd?

Ответить | Правка | Наверх | Cообщить модератору

283. "Релиз ядра Linux 6.2"  +1 +/
Сообщение от Аноним (283), 21-Фев-23, 12:08 
До SSD не способен, но сэкономить количество аппаратных прерываний, тем самым облегчив труд ОС, способен.
Ответить | Правка | Наверх | Cообщить модератору

335. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (-), 22-Фев-23, 12:41 
> Т.е.вы хотите сказать что волшебный буфер способен разогнать мою флешку до почти ssd?

RAM даже быстрее SSD. И да, идея такая что если вы копировали файло - оно мигом улетело, прога разблокировалась и вы можете что-то еще там делать. Не ожидая завершения операции. А оно там в фоне параллельно с вами допишется.

Можно даже стереть часть записываемых файлов на флешке, при этом, кстати, они вроде из page cache будут аннулированы - и что еще не успело на стораж - записываться вроде как передумает и будет отменено.

А можно полчаса смотреть на заблокированную программу. В MSDOS без smartdrv так и было - и это было крайне медленно и крайне печально. Хоть и надежнее, типа. В многозадачках это чуть менее зло но заблокированная на записи программа таки попахивает софтом под DOS и 1-задачностью.

Ответить | Правка | К родителю #282 | Наверх | Cообщить модератору

43. "Релиз ядра Linux 6.2"  +7 +/
Сообщение от n80 (?), 20-Фев-23, 15:04 
Система и не считает (например, umount не завершится, пока буфер не будет полностью сброшен), считают приложения, авторы которых не читали man fsync/fdatasync или читали, но забили т.к. в их времена объём ОЗУ был слишком маленьким, чтобы сброс буфера занимал заметное время. Только вот кто будет переписывать все эти приложения… Со стороны системы, впрочем, стоило бы vm.dirty_bytes и vm.dirty_background_bytes по умолчанию ставить не в 0, а в какие-то разумные значения, только вот тут поди подбери такую формулу для этих значений, чтобы и из встроенки никто не завопил, и из хостеров, и из тех кто на кластерах гоняет Linux. Да ладно, пусть не в ядре, но хотя бы в условно десктопных дистрибутивах могли бы значения по умолчанию сделать ненулевыми, так ведь и эти почему-то не делают.

Не то что бы сложно самому несколько строчек закинуть в /etc/sysctl.d/local.conf, но, видимо, и остальные пользователи на этом остановились и не пинают мейнтейнеров.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

63. "Релиз ядра Linux 6.2"  +/
Сообщение от noname322223 (?), 20-Фев-23, 16:15 
https://learn.microsoft.com/ru-ru/azure/azure-netapp-files/p...
Может vm.dirty_ratio  утановлен, тогда согласно доке vm.dirty_bytes устанваливается автоматически в 0.
Ответить | Правка | Наверх | Cообщить модератору

99. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (99), 20-Фев-23, 17:38 
>Со стороны системы, впрочем, стоило бы vm.dirty_bytes и vm.dirty_background_bytes по умолчанию ставить не в 0, а в какие-то разумные значения,

у меня от этого начинал тормозит tmpfs. Не понятно как такое вообще возможно, но в итоге лучше без прогрессбара чем с тормозящим всем.

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

101. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (99), 20-Фев-23, 17:43 
И не только у меня, на лоре куча жалоб вроде этой https://www.linux.org.ru/forum/linux-hardware/9052233
с единственным вменяемым советом не менять ничего в настройках io
Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

330. "Релиз ядра Linux 6.2"  +/
Сообщение от InuYasha (??), 22-Фев-23, 12:02 
> Им бы для начала вообще копирование на USB исправить, чтобы система не
> считала, что перенос в буфер == завершение копирования.

wait... ДО СИХ ПОР!?!? 8-o

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

336. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (-), 22-Фев-23, 12:46 
> wait... ДО СИХ ПОР!?!? 8-o

Некоторые так и на неучились флешки размонтировать. Хотя безопасное извлечение еще в Win98, кажется было. Если не в 95. До некоторых медленно доходит.

И слет только критичных частей ФС это еще не самое плохое. Если флеху абы как сдернуть, контроллер мог ворочать огромный блок и что он там потеряет кто ж его знает, ФС на урон измеряемый десятками мегов вокруг записываемой области за присест не расчитаны. Никакие по сути. Что хуже - может слететь трансляция и тогда если файлы нужны, узнаете зачем вон те фирмы сущестуют и сколько такая услуга стоит (хинт: не очень гуманно, но какой у вас выбор? Файлы потерять? Сильно повышает сговорчивость клиентуры!).

Ответить | Правка | Наверх | Cообщить модератору

360. "Релиз ядра Linux 6.2"  +/
Сообщение от InuYasha (??), 22-Фев-23, 21:50 
Да я, как бы, знаю, что лёликс не любит съёмные носители. Но у меня и версия старая. А что такое подолжается и поныне - это шок.
Ответить | Правка | Наверх | Cообщить модератору

365. "Релиз ядра Linux 6.2"  +/
Сообщение от Аноним (365), 22-Фев-23, 22:38 
> Да я, как бы, знаю, что лёликс не любит съёмные носители.

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

> Но у меня и версия старая. А что такое подолжается и поныне - это шок.

Шок это то что юзеры с 80х годов граблю так и не усвоили :). И нет, без буфера не прикольно - скорость падает сильно.

Ответить | Правка | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру