The OpenNET Project / Index page

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



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

Оглавление

Предложение по блокировке драйверов-прослоек, предоставляющих доступ к GPL-вызовам ядра Linux, opennews (??), 04-Авг-20, (0) [смотреть все]

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


13. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +43 +/
Сообщение от Zenitur (ok), 04-Авг-20, 11:35 
Как я понимаю, произошло вот что. В ядре Linux 3.5 появился механизм DMA-BUF. Этот механизм позволяет двум разным PID работать над одними и теми же данными в памяти. Лицензия на код DMA-BUF не позволяла проприетарным драйверам им пользоваться. В ядре Linux 3.9 появилась прослойка между DMA-BUF и проприетарными драйверами. После этого заработал Optimus (через механизм PRIME, это который не Bumblebee).

Прошло 7 лет. Разработчики Facebook добавили в код DMA-BUF - связь между GPU и сетевой картой. При этом они отправили патч не в сам DMA-BUF, а в код прослойки от NVIDIA, через которую они щупают DMA-BUF. Получилось так, что воспользоваться новой возможностью можно только на NVIDIA GPU, потому что драйверы Intel и AMDGPU пользуются DMA-BUF напрямую без прослоек, потому что это GPL-драйверы и им разрешено.

Посмотрев на это всё, один из разработчиков ядра сказал "ничего себе, как обнаглели проприетарщики. А давайте им запретим делать такие прослойки?"

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

21. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +13 +/
Сообщение от Аноним (21), 04-Авг-20, 11:47 
Тоесть они хотят снова сломать nvidia prime. Ге ни аль но
Ответить | Правка | Наверх | Cообщить модератору

29. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +1 +/
Сообщение от JL2001 (ok), 04-Авг-20, 11:56 
> Тоесть они хотят снова сломать nvidia prime. Ге ни аль но

нвидийцы (как и виндовчане и бсдешники) должны страдать
надо было думать, а не брать что в рот влезло

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

41. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +21 +/
Сообщение от Аноним (41), 04-Авг-20, 12:13 
Но окажется что пострадают только лишь линуксоиды.
Ответить | Правка | Наверх | Cообщить модератору

60. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +18 +/
Сообщение от Аноним (60), 04-Авг-20, 12:40 
... выбравшие nvidia
Ответить | Правка | Наверх | Cообщить модератору

71. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +5 +/
Сообщение от Аноним (71), 04-Авг-20, 13:00 
>... выбравшие nvidia

... как обычно.
похоже они группа мазахистов.

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

250. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  –2 +/
Сообщение от anonymous (??), 05-Авг-20, 10:21 
Лично мне нужна была CUDA. Это не делает из меня мазохиста.
Ответить | Правка | Наверх | Cообщить модератору

267. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (-), 05-Авг-20, 15:10 
> Лично мне нужна была CUDA. Это не делает из меня мазохиста.

Тебе нужна некая проприетарная шляпа от блобовендора. При чем тут разработчики линуха? Это твои интимные отношения с тем жлобовендором. Вот и разбирайся с нвидией где-нибудь в сторонке. Желательно свалив на винду или куда там еще, нахрен в линухе латентные маздайцы не сдались, чтобы всякие нвидии еще смели мнить что это ок. Черта с два, а не ок.

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

280. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +1 +/
Сообщение от anonymous (??), 05-Авг-20, 17:35 
Конечно, не при чем. Вот из отпуска вернуться, разгонят спиногрызов, до клавиатуры дорвавшихся... А там и каникулы закончатся, экспертам не до каментов на опеннете станет.
Ответить | Правка | Наверх | Cообщить модератору

309. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (-), 06-Авг-20, 11:18 
> Конечно, не при чем. Вот из отпуска вернуться, разгонят спиногрызов, до клавиатуры
> дорвавшихся...

Ггг ну вон тех то не разгонят, я весь тредик нашел - https://lore.kernel.org/netdev/6376CA34-BC6F-45DE-9FFD-7E326.../

Можешь самолично полюбоваться сколько и чего откушал чувак, сдуру удумавший апи с нвидии слизать и брякнувший про свой GPU. Ну ему всей толпой и объяснили его перспективы с его патчем. Далеко не в самом приятном виде, кто-то даже прямым текстом сообщил что он выбрал довольно эффективный способ заагрить на себя весь LKML :D

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

385. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от ммнюмнюмус (?), 10-Авг-20, 17:33 
А что, специальной поддержки сторонних модулей похоже никогда не было. Всегда надо было ставить или исходники или их усеченный вариант с одними заголовками, чтоб что-то для ядра собрать. А загрузка произвольных модулей - возможно, скорее отладочная опция, почти как рутование андроида.
Ответить | Правка | Наверх | Cообщить модератору

295. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от anonymous (??), 06-Авг-20, 00:20 
правильно. Фактически nvidia продаёт CUDA - уникальную библиотеку, других в продаже нет. Но почему для продажи в качестве посредника должен выступать линукс? Пусть ваяют свою ОС или форкают какую-нибудь бздю. А то не хорошо, линукс в качестве посредника используют, а правила не хотят выполнять, обойти пытаются.
Ответить | Правка | К родителю #267 | Наверх | Cообщить модератору

300. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от anonymous (??), 06-Авг-20, 03:07 
"В сторонке" -- это где? Я уже лет 17 пользуюсь Linux и contribute-ю в около-Linux-проекты. Кто вы такой, чтобы указывать мне, на чём мне работать? Такой вот я пользователь Linux с такими вот интересами.
Ответить | Правка | К родителю #267 | Наверх | Cообщить модератору

310. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (-), 06-Авг-20, 11:22 
> "В сторонке" -- это где? Я уже лет 17 пользуюсь Linux и
> contribute-ю в около-Linux-проекты. Кто вы такой, чтобы указывать мне, на чём
> мне работать? Такой вот я пользователь Linux с такими вот интересами.

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

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

373. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от anonymous (??), 08-Авг-20, 16:08 
Я-то не против kernel team-а, а очень даже за. Но вы почему-то считаете, что kernel team против таких пользователей, как я. А это не так :)
Ответить | Правка | Наверх | Cообщить модератору

381. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (381), 09-Авг-20, 23:10 
> Я-то не против kernel team-а, а очень даже за. Но вы почему-то
> считаете, что kernel team против таких пользователей, как я. А это не так :)

Они не против пользователей как таковых. Но здорово против проприетары, особенно когда это начинает касаться их.

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

317. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от eee (??), 06-Авг-20, 13:48 
> Тебе нужна некая проприетарная шляпа от блобовендора. При чем тут разработчики линуха? Это твои интимные отношения с тем жлобовендором. Вот и разбирайся с нвидией где-нибудь в сторонке. Желательно свалив на винду или куда там еще, нахрен в линухе латентные маздайцы не сдались

откуда ж вы выползаете такие мамкины хацкеры... системы с нивидией на борту вытесняют потихоньку остальных с топ500 - может им предложишь тоже на венду свалить?

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

337. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (-), 06-Авг-20, 18:22 
> откуда ж вы выползаете такие мамкины хацкеры... системы с нивидией на борту
> вытесняют потихоньку остальных с топ500 -

IIRC последние несколько лет это уже не так и там пошел процесс вытеснения ASIC'ами с специализированными акселераторами и все это ессно на ARM, который как раз подходящий конструктор для чипмейкеров.

Может нвидия именно поэтому и хочет ARM купить? Однако дело в том что процесс уже пошел и не остановится. Вон у теслы (автомобильной) чипак автопилота, с 2-я кластерами акселераторов, по 36 TOPS каждый, при том int8 вообще, что забавно. Это они оптом накопипастили под нейросеточки спецом. И вот такого добра уже развелось довольно много, и активно строгается новое. Оно ясен хрен утыкает нвидии в своей области куда не светит солнце.

> может им предложишь тоже на венду свалить?

Я предложу подождать немного и посмотреть что будет :). И кстати сказки о том как нвидия всех без вазелина - я уже i++'й год слышу. Но пока почему-то только нвидию, тем же GPL_ONLY например.

А, да, даже тот чувак на вопрос "чего не GPL_ONLY" сказал что ща пофиксит. А ему походу не принципиально, он тупо не в курсе был.

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

355. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (355), 07-Авг-20, 14:59 
> IIRC последние несколько лет это уже не так и там пошел процесс вытеснения ASIC'ами с специализированными акселераторами и все это ессно на ARM, который как раз подходящий конструктор для чипмейкеров.

Где вы такие беретесь. ASIC это заказная микросхема с фиксированной логикой. GPU более универсально.
Ты точно не спутал с биткоинами ?

> И кстати сказки о том как нвидия всех без вазелина - я уже i++'й год слышу.

Достаточно посмотреть на TOP500.. и да, без вазелина и вынести ее оттуда будет сложно.

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

360. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (360), 07-Авг-20, 17:30 
> Где вы такие беретесь. ASIC это заказная микросхема с фиксированной логикой. GPU
> более универсально.

Ржал аки конь. Загрепайте сорцы AMDGPU по слову ASIC. ASIC'и разные бывают. Некоторые такие уж и фиксированные вот.

> Ты точно не спутал с биткоинами ?

Для тех кто в танке: ASIC = application specific integrated circuit. Тут вообще ни звука про то фиксированная логика или нет. Т.е. это чип адаптированный под задачи. Если кто думает что GPU не адаптирован к задачам, может попробовать запустить не параллелящийся алгоритм с интенсивным управлением control flow и ощутить какой он general purpose cpu.

>> И кстати сказки о том как нвидия всех без вазелина - я уже i++'й год слышу.
> Достаточно посмотреть на TOP500.. и да, без вазелина и вынести ее оттуда будет сложно.

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

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

368. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (368), 08-Авг-20, 06:12 
> Для тех кто в танке: ASIC = application specific integrated circuit. Тут вообще ни звука про то фиксированная логика или нет

Ты точно знаешь перевод того что процитировал ?:) Вот на GPU я могу считать разные алгоритмы - а на ASIC прошитом под обработку звука я ничего другое уже не сделаю. Указывать ограничения GPU не стоит, но он значительно более general purpose чем ASIC. И говорить что ASIC будут иметь хоть какое-то значение в TOP500.. удачи парень.
Но лучше чуток верить тем кто это все железо видел и знает что там и как под капотом.


> И если они не сменят курс, то когда-нибудь доиграются, имхо.

Не.. тут доиграется линукс. Как не жалко. И как не смешно.


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

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

Но в нормальном мире - все строится совсем иначе. Люди любят своих детей, любят свою семью и им просто нравится работать и создавать. И им совсем все равно какой инструментарий будет, и что там сказал какой-то Линукс.
Если в следующем году - скажут что linux на помойку - переходим на BSD, спокойно доучат нужное и пойдут работать - развивать продукт дальше. В отличии от фанатиков - которых прийдется выкинуть на помойку.

А вот твой бизнес точно прогорит - от того что ты выбираешь решения не по эффективности, а по мнению какого-то чувака.
Можешь поиграть в открытость - но посмотри бизнесы тех кто продают открытые ноутбуки, openpower, всякие телефоны - они процветают? Это при том что на НИОКР они не тратятся - как правило их работа сводится к замене блоков на что-то открытое, а само железо не создают. Ты видишь в какой они жопе и как много у них покупают? Вот после этого можно легко сделать вывод о успешности бизнеса.

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

PS.
вижу конструктивное обсуждение закончилось и местному фанатику сорвало крышу от фактов реального мира - за сим откланиваюсь.

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

382. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (-), 09-Авг-20, 23:55 
> Ты точно знаешь перевод того что процитировал ?:)

У меня в отличие от вас с инглишем нормально. И поэтому я в курсе что в эту формулировку вообще не входит какая-то там (не)возможность замены алгоритмов.

p.s. первые GPU, внезапно, были fixed-function.

> Вот на GPU я могу считать разные алгоритмы - а на ASIC прошитом под обработку
> звука я ничего другое уже не сделаю.

Не мешает AMD обзывать GPU ASIC'ами. Мораль сей басни такова: ASIC разные бывают.

GPU - вполне себе application specific. Достаточно на устройство посмотреть.

> Указывать ограничения GPU не стоит, но он значительно более general purpose чем ASIC.

Это перепрограммируемый ASIC. А сейчас и другие появились - NPU набирают обороты. Специфичные дизайны для запуска нейросеток крупным оптом. Там перепрограммируемость еще меньше, оно обычно умеет несколько простых операций. И поэтому перепрофилировать такие вещи с нейросетей на что-то иное если и можно - то ограниченно. Это весьма редуцированные ALUшки под задачу. Зато очень крупным оптом. Счет идет на десятки-сотны, а порой и тысячи TOPS. И какая-нибудь тесла по соотношению жрача и счета разумеется выглядит очень вяло по сравнению с этими "brain chip" (название придумал IBM, который и запилил одним из первых подобное).

Отдельные умники уже пытаются скрестить SRAM и ALU дабы хардварныt аналогb нейрона былb значительно правдоподобнее - и при этом оно сразу локальной памятью для своих операций и подперто. Каждый нейрон.

> И говорить что ASIC будут иметь хоть какое-то значение в TOP500.. удачи парень.

ASIC разные бывают. Акселераторы тех или иных вычислений - тоже ASIC, различной степени программируемости. Ну вон тесла (масковская, автомобильная) сделала чипак под автопилот, обвешеный нейроакселераторами вместо всяких GPU. А для общей координации там 12 Cortex A72 еще до кучи, и вроде какой-то GPU, но самое интересное что там есть - тераопсы в int8 оптом для нейросеток. И вот так оно, пожалуй, постепенно научится не очень похабно педалить. Без всяких нвидий под капот, прожорливых и близко не устраивающих автомотивщиков по параметрам.

> Но лучше чуток верить тем кто это все железо видел и знает что там и как под капотом.

Погнощик слонов может абсолютно не рубить в анатомии. Даже если видел кучу слонов и научил их таскать бревна. Так что не аргумент.

>> И если они не сменят курс, то когда-нибудь доиграются, имхо.
> Не.. тут доиграется линукс. Как не жалко. И как не смешно.

Это незначительный процент рынка для него.

> Вылезь из своего мирка localhost и посмотри шире. Фанатики вроде тебя очень
> удобны своей предсказуемостью.

Мне кажется, если я осознал что ASIC необязательно fixed function и даже набрел на любопытные дизайны всяких странных штук - большой вопрос кому тут рассуждать про кругозор.

> Их удобно использовать [..бред заскипан..]

Это проекции ваших проблем на меня? Меня хрен поэксплуатируешь. Я сам себе эксплуататор.

> Но в нормальном мире - все строится совсем иначе. Люди любят своих
> детей, любят свою семью и им просто нравится работать и создавать.

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

> И им совсем все равно какой инструментарий будет, и что там
> сказал какой-то Линукс.

Спасибо, у меня есть свое характерное мнение о тех кому все-равно. И об их продукции. Насмотрелся на такое в СССР, всяких бездарей по распределению. Добавки не надо.

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

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

> А вот твой бизнес точно прогорит - от того что ты выбираешь
> решения не по эффективности, а по мнению какого-то чувака.

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

> Можешь поиграть в открытость - но посмотри бизнесы тех кто продают открытые
> ноутбуки, openpower, всякие телефоны - они процветают?

Есть ряд весьма неплохо ощущающих себя контор. Да и процветание - понятие растяжимое. Эпл конечно делает миллионы девайсов. Но их экосистема больше всего напоминает ставку гестапо, а их фабрики - трудовой лагерь. И если кто-то хочет сказать что это и есть процветание, я готов с этим поспорить. Процветание оно лишь для небольшой верхушки. А для всех остальных... эм...

> Это при том что на НИОКР они не тратятся - как правило их работа сводится
> к замене блоков на что-то открытое, а само железо не создают.

Да вот железячники удумали тут борзеть - и поэтому открытое железо тоже видите ли стало трендом. Ну и знаете, я печатки в KiCad рисую, так что мысль о том что я такой-сякой, железо не создаю - таки несколько преувеличена. А вот таки создаю порой. И таки в открытом софте. И не испытываю проблем отдать кастомеру пакет документации, включая печатки всяких "аддонов" потребные для его задачи. Ну, собсно, это application specific нечто - и поэтому китайцы могут копипастить до упора. Пойнт не в том - пойнт в том что я для соседней задачи новое такое нарисую, лучше туда лезущее, в весьма обозримые сроки. А, что вы там кстати говорили про созидание? :)

> Ты видишь в какой они жопе и как много у них покупают? Вот после этого можно
> легко сделать вывод о успешности бизнеса.

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

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

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

> вижу конструктивное обсуждение закончилось и местному фанатику сорвало крышу от фактов
> реального мира - за сим откланиваюсь.

Походу и правда снесло. Я б тоже взвыл будучи прикован к галере :)

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

135. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +2 +/
Сообщение от Аноним (135), 04-Авг-20, 16:26 
> ... выбравшие nvidia

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

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

110. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  –1 +/
Сообщение от Аноним (110), 04-Авг-20, 15:04 
>пострадают только лишь линуксоиды

Они же - Воронеж!

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

134. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (135), 04-Авг-20, 16:24 
Разработчики Linux предусмотрительно не юзают нвидии - иначе бы они не смогли быть разработчиками, т.к. хрен ту блоботу запустишь с новым ядром.
Ответить | Правка | Наверх | Cообщить модератору

90. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  –1 +/
Сообщение от pvsur (?), 04-Авг-20, 13:41 
На старом самсунговом ноуте от работодателя Прайм завелся, но машина стала еле ворочаться. Слайд-шоу дикий, хотя конфигурашка нвидиа говорит что все норм и директ рендеринг работает на ура. На фига такой Прайм, я так и не понял, перешёл на режим встроенной карты...
Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

130. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +1 +/
Сообщение от Аноним (-), 04-Авг-20, 16:15 
> Тоесть они хотят снова сломать nvidia prime. Ге ни аль но

А им на этот нвидиячототам пофиг. У них видите ли есть своя технология DMA BUF, для кидания между GPUшкой и чем-нибудь еще (изначально фреймбуфером иного GPU, но вот это уже не принципиально).

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

148. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от anonymous (??), 04-Авг-20, 16:50 
пусть пишут в юзерспейсе. Никто не мешает тащить проприетарь в юзерспейс. А в ядро - нини.
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

55. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +13 +/
Сообщение от анонимус (??), 04-Авг-20, 12:35 
Патчи довольно мутные сами по себе (конкретно заточены под костыли невидящих), а недовольство возникло сперва у Грега который несколько офигел с такой наглости проприетарщиков и попросил у товарища одобрение юриста потому что благодаря таким патчам можно вполне словить иск от NVIDIA. Товарищ стал переобуваться на ходу и сказал что только предлагает такой функционал и вообще от этих патчей и другим будет неплохо. Уже в ответ на это Кристоф написал свой патч который закрывает дырку с нарушением гпл, предложенную в патче.
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

274. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +2 +/
Сообщение от An0n (?), 05-Авг-20, 16:28 
> функционал

функциональность

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

57. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +4 +/
Сообщение от Аноним (355), 04-Авг-20, 12:35 
> Разработчики Facebook добавили в код DMA-BUF - связь между GPU и сетевой картой.

Там не совсем DMA BUF.. Там нужна возможность произвольно мапить PCI BAR куда надо.
А в DMA-BUF используется память из HOST с одновременным доступом двух устройств (если склероз не изменяет)
Но товарищи из Mellanox это все отлично делали и без патча на ядро.. Нафига козе баян был..

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

131. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (-), 04-Авг-20, 16:16 
> Но товарищи из Mellanox это все отлично делали и без патча на
> ядро.. Нафига козе баян был..

Где товарищи из mellanox крупным оптом гоняли картинку из одного GPU в другой с хоть каким оффлоадом? :)

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

208. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +1 +/
Сообщение от Аноним (355), 04-Авг-20, 21:55 
Именно так. Гуглить умеешь? тогда найдешь репы на GitHub.

PS.
Если ты в курсе как формируются WR для IB Verbs - то понимаешь что для WR chain глубоко пофик где находятся данные в соседних WR. А NVIdia для Tesla K100+ предоставляет средства заманить PCI BAR память карты в память ядра / процесса (поройся в репе - найдешь это). Получив адрес - можно гонять в первом WR любой offload который положат в буфер приложения - а сами данные попрут в буфер GPU.

PPS. Код мужика позволяет сделать нечто подобное для TCP.. но то такое - кому этот TCP нужен в HPC..

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

260. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +1 +/
Сообщение от Аноним (-), 05-Авг-20, 13:48 
> Именно так. Гуглить умеешь? тогда найдешь репы на GitHub.

Меня не интересует ни нвидия, ни infiniband, just in case...

> Если ты в курсе как формируются WR для IB Verbs

Infiniband вне сферы моих интересов, так что не в курсе. Зато более-менее в курсе что есть dma-buf. Это такое api для совместного использования буфера (потенциально подпертого DMA) на несколько железок. Изначально задумано для "headless" GPU, которые могут зарендерить, но у которых нет своей железки гонящей буфер в провод ("CRTC"/"display controller"). При этом в двухGPUшных девайсах и эмбедовке где display controller и GPU разные вещи как раз надо что-то такое. Как и некоторым V4L2 и проч (device <-> device, например camera -> HW encoder видео).

> - то понимаешь что для WR chain глубоко пофик где находятся данные в соседних WR.

Я не в курсе анатомии и терминов IB, сорь.

> А NVIdia для Tesla K100+ предоставляет средства заманить PCI
> BAR память карты в память ядра / процесса (поройся в репе - найдешь это).

Они что, PCI BAR по сети хотят гнать? А это вообще эффективно?

> PPS. Код мужика позволяет сделать нечто подобное для TCP.. но то такое
> - кому этот TCP нужен в HPC..

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

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

265. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (355), 05-Авг-20, 15:05 
>Infiniband вне сферы моих интересов, так что не в курсе.

Ну тогда представь что у тебя есть карточка со своей наборной памятью, которая умеет быть PCIe bus master, и умеет получать команды в виде {phys_addr, size} для передачи в сеть. эти командочки могут объединяться в цепочки причем требований к последовательности адресов в соседних командах нету, только в пределах одной команды.


> Зато более-менее в курсе что есть dma-buf. Это такое api для совместного использования буфера (потенциально подпертого DMA) на несколько железок.

скорее "менее" чем более. Тогда знал бы что DMA-BUF использует память хоста. Да - потенциально можно гонять на разные железки - но память хоста. Ибо сделано под наколеночные решения Intel - у которых видюха живет в памяти хоста.


>Они что, PCI BAR по сети хотят гнать?

ДА. И гоняют. Причем в отличии от этой наколенной реализации, реализация over IB позволяет гонять совершенно произвольный размер заголовка, а не fixed size & TCP only как в прототипе от facebook.

> А это вообще эффективно?

Как не странно да - особенно на последних AMD. Когда данные не гоняются 2 раза по PCIe - сначала в память хоста, а потом в память сетевухи. При этом Хост может еще и обмениваться с каким нить NVMe потоком данных. Детали можно почитать на сайте Nvidia/Mellanox по слову GPU direct.

Ну и что-то там намерил товарищ из Facebook - тоже интересные цифры.

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

269. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (-), 05-Авг-20, 15:52 
> Ну тогда представь что у тебя есть карточка со своей наборной памятью,

...
Вроде уловил общую идею. GPU так в принципе тоже до некоторой степени могут, но более статично и не по сети. Там это не проблема, а вон то звучит как 100% дыра в безопасности, если такие команды и на вход можно (плюс-минус iommu).

> скорее "менее" чем более. Тогда знал бы что DMA-BUF использует память хоста.

Ну да, хоста. Хотя в современных GPU с набортной памятью все стало довольно хитро.

> Да - потенциально можно гонять на разные железки - но память
> хоста. Ибо сделано под наколеночные решения Intel - у которых видюха
> живет в памяти хоста.

У амд в их APU тоже. Они это как фичу рассматривают: cpu и gpu могут шарить буфер между собой напрямую, zero-copy. Это просто, дешево, сердито и лучше чем было. А поскольку типовой сценарий работы с gpu так и выглядит, убить фазу трансфера/копирования - WIN. Это правда не поможет когда оба упрутся в одну и ту же DDR3/4, которая для GPU ни о чем. А у dGPU отдельная память. Амд сделали dGPU похожими на cpu.

Что до памяти хоста - ну, со стороны хоста она хоста. Логично. А со стороны железки она железкина: у амд dGPU оперирует в терминах своих адресов. И получается что в системе аж 3 вида page faults: CPU, IOMMU, и GPU. CPU сам по себе ничего не знает о адресах GPU, как впрочем и gpu о сpu'шных. Там вообще есть некая симметрия. С обоих сторон линка у железок есть dma движки и когда они хотят между собой блок пульнуть, заряжают DMA с обоих сторон и забывают об этом - у GPU на его стороне для обслуживания шины (и не только) тоже dma-движки есть, которые ессно адресами в пространстве gpu ворочают.

> ДА. И гоняют. Причем в отличии от этой наколенной реализации, реализация over
> IB позволяет гонять совершенно произвольный размер заголовка, а не fixed size
> & TCP only как в прототипе от facebook.

Черт, мсье знают толк...

> Как не странно да - особенно на последних AMD.

Никогда бы не подумал. Хотя в принципе оно так изначально заточено блоки туда-сюда гонять с подпором DMA с обоих сторон двери и если это не сильно портить а сеть быстрая...

> Когда данные не гоняются 2 раза по PCIe - сначала в память хоста, а
> потом в память сетевухи.

p2p транзакция сетевка <-> GPU, в обход cpu? А в этом что-то есть.

> Nvidia/Mellanox по слову GPU direct.

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

> Ну и что-то там намерил товарищ из Facebook - тоже интересные цифры.

Они как-то не с того конца яйцы чистить начали. Если они хотели что-то такое, логично было амдшников припахать и с ними и остальными подумать как в линухе какие-то хелперы/апи для сетапа железок в таких позах сделать. А проблемы нвидии кернельных девов видите ли ниипут, настолько что K-H довольно кислотно потроллил. И если вас троллит K-H - это очень плохой признак :)

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

273. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (355), 05-Авг-20, 16:09 
> а вон то звучит как 100% дыра в безопасности, если такие команды и на вход можно

только через спец софт. + у IB свои достаточно навороченые средства защиты - ибо там по любому network DMA.


> Они это как фичу рассматривают: cpu и gpu могут шарить буфер между собой напрямую, zero-copy. Это просто, дешево, сердито и лучше чем было.

только для десктопов это zero-copy. А если у тебя PCIe и так забито другим трафиком?.. какое тут zero-copy когда ты трафик 2 раза по PCIe гоняешь ? Что будет если тебе надо прогнать 256G туда<>назад? не считая того что эти 256G надо найти еще в вычислительной ноде, а потом они просто простаивать будут, что плохо скажется на цене и надежности решения. Вообщем стоит задуматься.


>Никогда бы не подумал. Хотя в принципе оно так изначально заточено блоки туда-сюда гонять с подпором DMA с обоих сторон двери и если это не сильно портить а сеть быстрая...

100-200 Gbit/s - быстрая сеть или нет?.. PCIe gen3 x16 накрывает, gen4 x16 тоже можно напрячь не слабо.

> p2p транзакция сетевка <-> GPU, в обход cpu? А в этом что-то есть.

Наконец-то.

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

Предлагаю сходить на сайт Mellanox - правда он собственность Nvidia - но вот так уж.. Или на GitHub в раздел Mellanox и посмотреть код.

> И если вас троллит K-H - это очень плохой признак :)

Это совсем ничего не означает. Если чувак не смог понять - что ради его хотелок никто не будет ложить кластера из TOP500 что бы код выглядел как он хочет быстро, то это проблемы K-H. Остальной мир HPC обойдется (как обходился с 2000 года) без lustre в staging. Это лишь означает меньше фрагментацию платформы ибо протестить 5-8 конфигураций - это вам не тестить постоянно меняющийся upstream.
Товарищи из Mellanox пошли так делать в OFED - качество на выхлопе упало сильно.
Делаем выводы.

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

286. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (-), 05-Авг-20, 22:03 
> только через спец софт.

Команда с адресом, которая как я понимаю исполняется и быстро, выглядит подозрительно, и еще до софта.

> + у IB свои достаточно навороченые средства защиты - ибо там по любому network DMA.

У новых чипсетов в теории еще IOMMU есть, но насколько им эффективно и безопасно сейчас пользуются - черт его там знает. А в p2p транзакциях iommu вообще наверное not in effect. Да и откуда б ему знать как защищать один девайс от поползновений второго. Это по сути новый, неизученный класс проблем.

> только для десктопов это zero-copy.

Да, это для десктопов имеет смысл. При том с малохольной графикой - более приличной DDR3/4 напополам с процом всяко мало. Даже GDDR5 на широкой шине в графических задачах быстрее, и выделенный, а HBM какой так и вообще.

> А если у тебя PCIe и так забито другим трафиком?..

Майнеры x1 линком были довольны - грузили в GPU большой джоб, через уйму времени забирали результат. Но можно ли так от задачи сильно зависит.

> какое тут zero-copy когда ты трафик 2 раза по PCIe гоняешь ?

По pcie уже не zero copy, разумеется. А тут им напрашивается идеся скрестить сетевку с видяхой. И вообще им там какой-нибудь on-chip super-link между ip-блоками логичнее было бы, там может быть сильно больше pcie. Но вот это, от нвидии? Wouldn't touch it with 10' pole.

> Что будет если тебе надо прогнать 256G туда<>назад? не считая того что эти
> 256G надо найти еще в вычислительной ноде, а потом они просто простаивать
> будут, что плохо скажется на цене и надежности решения. Вообщем стоит задуматься.

Так то я пожалуй согласен что в такой идее что-то есть, а dma-buf все же о другом. Однако идея что нвидия и сетевка будут делать dma друг в друга, да еще без хоста наводит на меня благоговейный ужас. А нвидии было бы логично скрестить это в одну мегажелезку, чтобы вообще не утыкаться в pcie. Что они там на чипе гоняют или inter-chip на короткие дистанции так всем вообще похрен. GPU даже тоже такое пытались с своими inter-gpu линками, типа crossfire и как там оно у нвидии. Но это специфичная штука, настолько что в лине вроде до сих пор амд ее не накодили.

> Наконец-то.

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

> Предлагаю сходить на сайт Mellanox - правда он собственность Nvidia - но
> вот так уж.. Или на GitHub в раздел Mellanox и посмотреть код.

Видимо все же стоит, про p2p в pcie любопытно. Вроде не видел до этого осмысленного юзежа.

> Это совсем ничего не означает.

Это означает что остальные вас вообще пожарили бы на медленном огне.

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

У K-H в контексте разработки кернела если и бывают проблемы то совсем иного плана. Какой-то оверрайд слова K-H в кернеле вообще может только Торвальдс, а тот очень не любит спорить с K-H доверяя его judgement. Поэтому если KH кого-то троллит... да, блин, удачи с патчами...

> Остальной мир HPC обойдется (как обходился с 2000 года) без lustre в staging.

ЧСХ это будут проблемы мира HPC обитателям которого придется больше пахать. А вот KH из проблем блобов нвидии свои проблемы делать явно не станет. Как и все остальные. Так что они на раз достанут из карманов свои NAKи за такие вещи.

> Это лишь означает меньше фрагментацию платформы ибо протестить 5-8
> конфигураций - это вам не тестить постоянно меняющийся upstream.
> Товарищи из Mellanox пошли так делать в OFED - качество на выхлопе
> упало сильно.Делаем выводы.

Ну как бы это проблемы товарищей из Mellanox. Если кто попер с патчами в ядро, видимо идея была все же избавиться от части проблем там и вгрузить в майнлайн. Но до этого можно было и поинтересоваться наверное совсем уж базовыми dos и donts. Получить троллинг от KH это таки achievement of life.

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

301. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +1 +/
Сообщение от Аноним (368), 06-Авг-20, 05:56 
>Команда с адресом, которая как я понимаю исполняется и быстро, выглядит подозрительно, и еще до софта.

команда с адресом привязана, к memory domain id, которые имеет свои security attributes и тп.. там достаточно проверок и без IOMMU. IB спек разрабатывался долго и с большой оглядкой на безпасность. Начиная с тех времен когда Linux под стол пешком ходил (первые патчи на network rdma были на linux 2.2 - потом это стандартизировалось и оформилось в OFED).

>Майнеры x1 линком были довольны - грузили в GPU большой джоб, через уйму времени забирали результат. Но можно ли так от задачи сильно зависит.

кроме майнеров есть еще РосГидромет (Cray XC40 + tesla /если не путаю спеку/). Кроме того - данные в эту ситевку должен кто-то вливать с той стороны - а занятость сетевых линков тоже вещь такая.. очень плохо влияет на MPI (см. историю появления Cray interconnect - SEASTAR/BlackStar).

> А нвидии было бы логично скрестить это в одну мегажелезку, чтобы вообще не утыкаться в pcie.

Зачем? дороже в производстве а получается очень нишевый продукт.

> Поэтому если KH кого-то троллит... да, блин, удачи с патчами...

Поэтому КН послали на юх.. собака лает караван идет.
И спокойно продолжают разработку - допиливая фичи которые реально нужны клиентам.
Раз в 5 лет при выходе очередного дистрибутива redhat/suse - можно слегка напрячься скооперироваться с разрабами оттуда и допилить прослойку совместимости.

> ЧСХ это будут проблемы мира HPC обитателям которого придется больше пахать

Если обитателям мира HPC прийдется больше пахать, то есть не нулевой шанс что Торвальдсу напомнят кто его кормит, или вообще свалят на что другое. В большом мире решают не абстрактные мысли о свободке, а вполне реальные цифры затрат на достижение определенней производительности. Если эта производительность может быть достигнута на другой платформе с меньшими затратами - то Linux умрет. Стоит только напомнить что эти люди подарили Linux - ext3(проект ldiskfs)/ext4 (да да, то что называется ext4 это проект ldiskfs2).

Возвращаясь к Lustre - она всегда поддерживала большой диапазон ядер которые стоят у клиентов. Никто из больших кластеров не будут обновляться до последнего mainline что бы получить какой-то багфикс. Вот как-то так.
А патч с убираем EXPORT_SYMBOL_GPL - очень дешев.


>Ну как бы это проблемы товарищей из Mellanox. Если кто попер с патчами в ядро, видимо идея была все же избавиться от части проблем там и вгрузить в майнлайн.

Mellanox выложил свой код 4 года назад. Учитывая объем - где-то в 500-1000 строк, там поддержка требуется крайне редко.
https://github.com/Mellanox/nv_peer_memory
https://github.com/Mellanox/gpu_direct_rdma_access
Все тривиально до жути - CUDA предоставляет функции замапить PCI BAR в память ядра и(или) процесса.
Потом этот же адрес можно использовать как аргумент для cuda программ которые выполняются на GPU.

Facebook решил себе облегчить жизнь и пихнуть его в mainline зачем-то. Так что приплетать Mellanox туда совсем не стоит.

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

311. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (-), 06-Авг-20, 12:49 
> разрабатывался долго и с большой оглядкой на безпасность.

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

> кроме майнеров есть еще РосГидромет (Cray XC40 + tesla /если не путаю спеку/).

"А что так хорошо, доктор? Хорошо что это не у меня!"

> очень плохо влияет на MPI (см. историю появления Cray interconnect - SEASTAR/BlackStar).

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

> Зачем? дороже в производстве а получается очень нишевый продукт.

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

> Поэтому КН послали на юх.. собака лает караван идет.

Пруф? Я весь тредик почитал и не вижу кто там KH там послал. Алсо лает половина LKML, даже Мэйсон, из фэйсбука, который ФС пилит и знает и специфику фб, и dos/donts майнлайна тому чудику вежливо, но убедительно намекнул что он выбрал крайне хреновый способ для попадания в майнлайн - дескать, рекомендуется радикально пересмотреть курс действий. Нет, сколхозить тонкий shim относительно нвидияапи и выдать это как патчи в майнлайн решительно не проканает, а запал на этом крайне вреден для репутации wannabe-kernel developer.

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

Они могут хоть зеленых покемонов разводить, покуда это не затрагивает майнтайнеров майнлайна. А вот если это начинает колыхать оных - пааардон! Те сделают удобно себе, коллегам, своим фирмам и клиентам. А вот остальным - постольку поскольку. И соответственно это никак не про сдирание апи с нвидии, которой даже в кернеле нет.

> Раз в 5 лет при выходе очередного дистрибутива redhat/suse - можно слегка
> напрячься скооперироваться с разрабами оттуда и допилить прослойку совместимости.

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

> Если обитателям мира HPC прийдется больше пахать, то есть не нулевой шанс
> что Торвальдсу напомнят кто его кормит,

Его кормят явно не эти чуваки - от нвидии ни денег, ни патчей. А у конкретно редхата вся команда вокруг GPU на нвидию волком смотрит. Так что единственный кто в этой схеме будет икать - некооперативный проприетарщик и клиентура оного. Блин, даже MS сподвигся комитить свой крап на общих основаниях, усвоив что ежели хорошая работа продуктов и отсутствие трабл у кастомеров нужны, правильный курс дейтсвий - вот такой.

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

От отсутствия проприетарщиков с нвидией никто ничего не потеряет особо. Эти, видите ли, всегда норовят на чужом хребте в рай въехать. И в какие там васюки эти жлобы перенесут свою столицу - да это их проблемы.

> Если эта производительность может быть достигнута на другой платформе с меньшими затратами

Это такое очень большое "если". У остальных, видите ли, нет крутой и компетентной кернелтимы такого масштаба, освоившей совместную игру такого масштаба. И соответственно их кернелы находятся в куда более унылом состоянии. Ну и про меньшие затраты, производительность и проч речь не идет. Ядерщики линя отлично в курсе своего уровня и что именно его поддерживает. Поэтому периодически спрыскивают зарывающихся дустом. Что очень способствует поддержке проекта в форме. А вот этим вашим другим - фирма сони уже как бы _себе_ написала годную графику, а другим она _дырку от бублика_ подарила. И вот такие шоу линуксным ядерщикам вообще не втыкают, они серьезно намерены быть первым сортом, а не всеми забытой подложкой под проприетарные продукты.

> то Linux умрет. Стоит только напомнить что эти люди подарили Linux -
> ext3(проект ldiskfs)/ext4 (да да, то что называется ext4 это проект ldiskfs2).

Я btrfs использую. И подарили его по большому счету несколько конкретных чуваков - вон тот Мэйсон который ща в FB и те кто ему насоветовали cow-деревья. И технологически это был большой шаг вперед, а вы можете своим EXT* размахивать. Только это надо было цать лет назад делать. А основная заслуга корпов типа fb относительно него - да вообще мощный багтест и обезглючка. Это несомненно тоже надо, но присвоить себе лавры при этом все же не получится.

> Возвращаясь к Lustre - она всегда поддерживала большой диапазон ядер которые стоят
> у клиентов. Никто из больших кластеров не будут обновляться до последнего
> mainline что бы получить какой-то багфикс. Вот как-то так.
> А патч с убираем EXPORT_SYMBOL_GPL - очень дешев.

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

> Mellanox выложил свой код 4 года назад. Учитывая объем - где-то в
> 500-1000 строк, там поддержка требуется крайне редко.

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

> https://github.com/Mellanox/nv_peer_memory
> https://github.com/Mellanox/gpu_direct_rdma_access

У ядерщиков как раз там резонный вопрос возник - может быть, время для какого-то более generic апи для pci p2p? А то когда вот тут патч на частный случай, тут патч на частный случай, тут и тут... все это определенно катится в сторону лоскутного одеяла. И нет, такое устроить в майнлайне не дадут, они уже наелись на заре его вылупления, дважды на одни грабли они не встают.

> Все тривиально до жути - CUDA предоставляет функции замапить PCI BAR в
> память ядра и(или) процесса.

Ну вот там ядерщики и прошлись по этому моменту - мол, вы обуели драть апи 1 в 1 с нвидии вашей проприетарной.

> Потом этот же адрес можно использовать как аргумент для cuda программ которые
> выполняются на GPU.

Как круто. Нвидиевская проприетарщина еще и будет лупить в чужие железки, прям в их BAR. Выглядит апофеозом секурити. И так чисто по человечески, гидромету потом не надо обижаться, когда заодно там будет мини-штаб NSA пополам с представительством узкоглазых.

> Facebook решил себе облегчить жизнь и пихнуть его в mainline зачем-то. Так
> что приплетать Mellanox туда совсем не стоит.

Facebook регулярно это делает. И таки реально облегчает себе жизнь. Это для них, в отличие от нвидии, неплохо работает.

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

315. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +1 +/
Сообщение от Аноним (355), 06-Авг-20, 13:25 
> Так у них тоже получается нишевой продукт.

Вы серьезно не понимаете или прикидываетесь? Люди берут стандартную сетевую карту (напомню что ConnectX5/6 выпускается далеко не единичных маштабах) взяли обычный GPU и получили новое решение.
Если сильно хочется можно взять Mellanox BlueField и Nvidia GPU и получить ровно такое же решение.
и тп. при этом каждая часть этого решения может использовать еще в других местах.
Может это у вас проблемы с архитектурой, а не у них?

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

Их кастомерам плевать с большой вышки на маинлайн. Как вы этого не поймете. Они его не используют, это удел школьников. Они используют RedHat, SuSe на крайняк УБунту.. И свои производные которые и так оптимизированы для нужных вещей. Вы видели в маинлайне драйвера для Cray SeaStar? Cray BlackStar? Cray Aries? и стопку другого специфичного железа.
А это нефига не мешает создавать и продавать кластера - включая машинки из ТОР10. А теперь откройте интернет и найдите сколько кластеров из TOP500 использует что-то кроме redhat/suse/ubuntu ?
А я подожду пока вы считаете.

> И подарили его по большому счету несколько конкретных чуваков - вон тот Мэйсон который ща в FB и те кто ему насоветовали cow-деревья.

Да да.. утянутая с ZFS архитектура (как никак он посматривал из-за плеча старших товарищей на nfs), только вот навек не нужная. Как там рейд поживает? данные давно не теряли? Да и производильность почему-то вот..
ext4 выдает 140Gbyte/s на чтении, и 85 Gbyts/s на записи, данные последних тестирований новой дисковой полки.
(я не описался - размерность гигабайты в секунду).
может выдать btrfs такие цифры? Какой CPU load будет в этом случае?..

>От отсутствия проприетарщиков с нвидией никто ничего не потеряет особо.

В вашем мирке админов localhost - никто ничего не потеряет. Но если из linux свалит Nvidia - как говорили раньше - можно выкинуть linux из кластеров и TOP500, его там просто не будет. А в TOP500 будет то где будет Nvidia GPU. Советую это хорошо запомнить. Как не обидно. Можно говорить фак-ю nvidia, но попытка сделать больно - окончится концом кормушки.


>А вот этим вашим другим - фирма сони уже как бы _себе_ написала годную графику, а другим она _дырку от бублика_ подарила.

Давайте ответите на другой пример. Фирма Cisco - продает офигенные свичи/роутеры/и тп.. где в виде CLI стоит линукс.
Ответьте что она подарила ядру? Куда вообще вложилась?

> Он показал девам что некий пойнт у фичи все же может быть - и возможно было бы неплохо если бы кернел фичу умел.

Отлично. Сделают - NVdia реимплементит свой код через этот API. Пока у Nvidia единственный существующий API в этом роде. Других просто не существует. Как другие потянутся - так и можно что-то стандартизировать, а пока других нету.


> Как круто. Нвидиевская проприетарщина еще и будет лупить в чужие железки, прям в их BAR.

Не тупи. Nvidia BAR выступает источником памяти, а PCIe транзацию целиком организует Mellanox CX5/6.


>Пруф? Я весь тредик почитал и не вижу кто там KH там послал.

А подумать и посмотреть что случилось после того треда? Ах.. вынесли из staging.. теперь надо пойти застрелиться и умолять вернуть назад.
Только нефига. Это просто проигнорировали - ну там mr Broun из SuSe чет там лениво ковыряет на предмет готовности к upstream. Но где-то в сторонке и строго по процессу который принят в lustre, а не наоборот.
Засылание в upstream - было изначально хотелкой одного человека - вот пусть и вылизывает, остальным на него хотелки все равно. Есть roadmap продукта - в котором linux submission - не значится в даже в средних планах.

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

343. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (-), 06-Авг-20, 21:03 
> ConnectX5/6 выпускается далеко не единичных маштабах) взяли обычный GPU и
> получили новое решение.

Идея по своему прикольная. Нюанс в реализации и деталях. С чем автор патча и не спорит, кст.

> Если сильно хочется можно взять Mellanox BlueField и Nvidia GPU и получить
> ровно такое же решение.

Юзать линух в форматах навязываемых нвидией последнее что мне бы хотелось. Независимо от кульности идей и технологий.

> Может это у вас проблемы с архитектурой, а не у них?

Линуксные ядерщики выдали несколько иное мнение на этот счет и КМК у них есть некий пойнт. У них всегда есть пойнт.

> Их кастомерам плевать с большой вышки на маинлайн. Как вы этого не поймете.

Просто майнлайн никто не будет замусоривать нишевой штукой, нужной только нвидии. Это данность.

> Они его не используют, это удел школьников. Они используют RedHat,
> SuSe на крайняк УБунту..

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

> для нужных вещей. Вы видели в маинлайне драйвера для Cray SeaStar?
> Cray BlackStar? Cray Aries? и стопку другого специфичного железа.

Специфичные штуки, так что и фиг бы с ними. Кому они нужны решат свои проблемы.

> А я подожду пока вы считаете.

Если этот статус кво устраивает, набуя лезть с нвидиякрапом в майнлайн? Нвидию там не лю: 1 из самых мерзких и некооперативных вендоров.

> Да да.. утянутая с ZFS архитектура (как никак он посматривал из-за плеча
> старших товарищей на nfs),

В btrfs до того как делать посмотрели на чужие грабли, в т.ч. ZFSные. И подумали чего с этим делать. До того как подрыаться кодить. С backrefs неплохо придумали, как и с блочными группами. На мой вкус позитивная штука. Даже шляпа вроде признала.

> только вот навек не нужная.

Не знаю протянет ли дизайн век, но здесь и сейчас мне ОК :)

> Как там рейд поживает?

Я даже извраты типа DUP попробовал. "Eж пищит, орет, но живет" (c). Особенности остались с RAID56.

> данные давно не теряли?

Ее на фэйсбукохомяках неплохо отладили. А чексумы и проч к тому же информируют о проблемах задолго до того как трансформируется в что-то серьезное. А ZFS в линухе нафиг нужно имхо.

> Да и производильность почему-то вот..

Производительность как производительность. В отличие от ZFS cow выборочно отключается, если принципиально не ложится на ворклоад. На обычном десктопе, серваке и лаптопе - норм.

> ext4 выдает 140Gbyte/s на чтении, и 85 Gbyts/s на записи, данные последних
> тестирований новой дисковой полки.

Здорово и все такое, но, имхо, счастье не только в гигах в секунду. Если для вас это главное то у ext4 оверхеда меньше. И фич тоже: чудес не бывает.

> (я не описался - размерность гигабайты в секунду).
> может выдать btrfs такие цифры? Какой CPU load будет в этом случае?..

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

> linux из кластеров и TOP500, его там просто не будет.

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

> - окончится концом кормушки.

Разве что для eParasite'ов из нвидии. Куда и дорога этим господам, имхо. На форониксе нвидиевские методы вообще назвали "GPL Condom", гы :))

> Ответьте что она подарила ядру?

Да вроде шлют патчи. Хотя тоже так себе конторка конечно.

> Куда вообще вложилась?

В видеокодеки - Thor на растерзание отдали :). А нвидия вложилась в жабу, жабу и ничего кроме жабы.

> Отлично. Сделают - NVdia реимплементит свой код через этот API.

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

> Пока у Nvidia единственный существующий API в этом роде.

Нвидия линуксному ядру не указ.

> других нету.

Для нвидии в ядре никто суетиться не будет, там tit for tat видите ли.

> PCIe транзацию целиком организует Mellanox CX5/6.

А, ну в таком виде это еще не так стремно.

>>Пруф? Я весь тредик почитал и не вижу кто там KH там послал.
> А подумать и посмотреть что случилось после того треда?

Имхо, чувак отполз изучать как остальные дрова работают. Или забил. Мне его манагеров из мордокниги не видно. Зато видно Мэйсона оттуда же популярно объясняющего коллеге что тот ломает дров. Стоп, ему вроде про ломку дров сказал, даже, кажется, чувак с @nvidia.com?! Ох, WTF?! :D :D :D

> Ах.. вынесли из staging.. теперь надо пойти застрелиться и умолять вернуть назад.

Это про люстру? Ну, так вышло ее не майнтайнили, а здоровенный шмат кода вываленный абы как там не больно кому сдался. Это вам не бсд, где можно с лопаты, в лине такое быстро дропают, у них кодовая база большая и они не могут себе позволить такой хлам. Как начинает ломаться - после пары китайских предупреждений делают харакири. Ничего личного, чисто технические действа, элементарный health management проекта.

> Только нефига. Это просто проигнорировали -

Ну, если никому не надо то и нечего этому валяться в майнлайне. Майнлайн не помойка. Валить туда крап с лопаты никто не даст. И это тоже причина по которой мы любим пингвина. Если нечто в пингвине, это показатель определенных стандартов качества. А не так что вот вам тут с лопаты.

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

350. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (368), 07-Авг-20, 08:04 
> Линуксные ядерщики выдали несколько иное мнение на этот счет и КМК у них есть некий пойнт. У них всегда есть пойнт.

Они выдали какому-то левому чуваку из facebook - хз чего он полез туда.

> Просто майнлайн никто не будет замусоривать нишевой штукой, нужной только нвидии. Это данность.

Нужной в ядре только facebook. Остальные живут на внешнем модуле.

> Если этот статус кво устраивает, набуя лезть с нвидиякрапом в майнлайн?

Это один чудак из  facebook полез. Зачем? спросить их стоит - видимо дань моде.

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

NVidia там останется, как и появится та ОС которую выберут. Не будет пиара в linux, корпорации оттуда уйдут - скорость развития упадет до 0 (достаточно посмотреть вклад независимых разработчиков).
Так что там останется?

> А чексумы и проч к тому же информируют о проблемах задолго до того как трансформируется в что-то серьезное.

да да. checksums хорошо подсмотрены в zfs..А потом необходимости в zfs нету.  Но попробую показать на пальцах - что это все туфта.
Вот смотри - программа записала, где-то на пути изменился байтик, или баг в ядре - но до вычисления checksum дошло уже поврежденное. И чем поможет ваша хваленная checksum? а вот T10 DIF/DIX даже не даст записать ибо checksum идет рядом с данными.
Посмотрим с другой стороны - зачем проверять checksum на cpu - когда за нас это может сделать HBA?
А вот с поддержкой T10 в btrfs плохо, очень плохо. Особенно в рейд конфетах.

> Здорово и все такое, но, имхо, счастье не только в гигах в секунду. Если для вас это главное то у ext4 оверхеда меньше. И фич тоже: чудес не бывает.

Ясна. "потребности в колбасе нету". Что там вы говорили о архитектуре - совать все в один комбайн?
Хотя вполне можно разбить на уровни. Хотя бы как в zfs.
Ах да, где там parity desclustered raid в btrs? очень полезная штука что бы не было bootleneck на одном из дисков. А вот в zfs есть, в md raid есть. в btrfs нету. В нормальных уровнях raid - 5/6 тоже "нюансы" ? ну ну.. это предлагается пользовать mirror на объемах в 20P?
Опять потребности в колбасе нету?

> На уровне концепций, в больших масштабах я за распределенные структуры, если что.

Так это и есть распределенная структура. С объемами на 10-20 P... хотя откуда от админов localhost такие объемы.
Ничего что 1P это сейчас объем одной дисковой полки?

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

Спасибо посмеялся. Пиши еще :-)

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

361. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (361), 07-Авг-20, 19:29 
> Они выдали какому-то левому чуваку из facebook - хз чего он полез туда.

До того как это сделать он явно не повисел в lkml и коллег не поспрашивал. С учетом мыла bsd@ - может, решил что тоже катит "с лопаты"? :)

> Нужной в ядре только facebook. Остальные живут на внешнем модуле.

Сам по себе фэйсбук пытается быть приличной фирмой - комитит наработки апстримам. Но вот в данном случае факапчик вышел. Крупный корп без факапов как птица без крыльев.

> видимо дань моде.

Троллинг от K-H - это сильно, это стильно!

> NVidia там останется, как и появится та ОС которую выберут.

Само по себе это не делает никому ни холодно, ни жарко.

> Не будет пиара в linux,

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

> корпорации оттуда уйдут - скорость развития упадет до 0

У корпораций? :D А на что уйдут? Винда не адаптируется, макось не серверная толком, бзды не от мира сего. На фуксию? Хипстеры устали дрова на игогошечке писать.

А вот так дернешься, с той же убунты - и нет вокруг 25К пакетов и дебианщиков, знающих что есть продакшн. И теперь вместо apt install и работы через пару минут долботни в разы больше что-то. И вместо развития своих проектов какая-то левая возня.

> (достаточно посмотреть вклад независимых разработчиков).

Ну так со временем корпы нанимают наиболее вменяемых себе - и это все те же люди. И airlied и из редхата гамнокоду прекрасно отлупляет NAK. Даже дружбанам из интеля. Блин, он именно для этого там и обитает. Конечно можно рассматривать PM'ов и прочие QA как саботажников, но говорят что они это не для прикола.

> Так что там останется?

Да все то же что и было. HPC забавен статусно, но процент рынка довольно небольшой. Ну, кроме nvidia corp, пожалуй - но вот это их проблемы, у них кроме GPU нет ничего. И то большинство скупают зерглинги-геймеры берущие числом.

> да да. checksums хорошо подсмотрены в zfs..А потом необходимости в zfs нету.

Ну да. И вообще это работает.

>  Но попробую показать на пальцах - что это все туфта.

Не соглашусь насчет туфты, поюзав это на практике.

> Вот смотри - программа записала, где-то на пути изменился байтик,

Будет CSUM ERROR: при чтении блок vs csum не сойдется. Вероятность что вторую (для особых параноиков i-ю) копию блока постигла та же участь - микроскопическая. И в этом месте теорвер уже за нас.

> или баг в ядре -

Эти господа конкретно затарились дустом. Вон syzbot ядро с kasan'ом мучает. Сам баги пишет, сам бисектит, может и мылы накосячившим шлет. Да и фс тестами обложили конкретно, btrfs'ники без ложной скромности xfs test suite юзают поболее самих XFS'ников. Миллиард хомяков фб поляну тоже вытоптали.

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

> но до вычисления checksum дошло уже поврежденное. И чем поможет ваша хваленная checksum?

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

Практически, чексумы...
1) Прекрасно парируют "разовые" взбрыки UNC ("bad sector") и прочей трухи из накопителя (ну там фирмваре сдурело/ребутнулось).
2) Подсвечивают явно сбойное железо задолго до того как это серьезно угробит что-то.
3) Неплохо чинит все это если есть откуда.
4) И вообще, неплохо справляется даже с откровенно дурными ситуациями. Хоть и не обязано.

> а вот T10 DIF/DIX даже не даст записать ибо checksum идет рядом с данными.

Где-то это и вариант, но далеко не везде где используется Linux.

> Посмотрим с другой стороны - зачем проверять checksum на cpu - когда
> за нас это может сделать HBA?

Может быть, затем что это делает дохрена допущений относительно железа? И вообще, как угодно но опенсорсный софт делом доказал что он куда менее стремный и более предсказуемый чем всякие мутные блобвари, делающие хрен знает что. А если это вдруг не так, это можно починить.

> А вот с поддержкой T10 в btrfs плохо, очень плохо. Особенно в рейд конфетах.

Оно как бы здорово, но вот на моем ноуте btrfs парировал рандомный бэд. А ваш вариант мне бы не помог и я бы, вероятно, систему перекатывал. Из-за 1 бэда в дофига лет. После такого showcase польза запасного парашюта понятнее :P.

> совать все в один комбайн?

Это имеет свои минусы, несомненно. И свои плюсы. Да, потенциально кто-то еще мог бы захотеть сравнимые технологии. Реально таковых нет - остальные делали здорово иначе, общего знаменателя толком нет.

> Хотя вполне можно разбить на уровни.

Оно реюзает алгоритмы и facilities ядра где это возможно. А механика с block groups, разными уровнями избыточности для данных и метаданных и проч - достаточно кастомная, остальные об этом не задумывались и у них этого нет. И инфраструктуры под это нет.

> Хотя бы как в zfs.

А его дизайн может в произвольную смесь уровней RAID и конверсию оных на лету? Вплоть до отскребания после ребута и продолжения операции с места краха?

B btrfs это следствие фокуса block groups и того что их схемы хранения могут быть разными. Это не менеджится как блочный RAID, в первом приближении можно обозвать это "пофайловым RAID", чтоли, это не точно - метаданные, допустим, не файлы, но у их блоков тоже своя схема хранения, не обязательно та же что у данных. В силу относительной уникальности такого дизайна и совершенно иных подходов у других не понятно кому эти уровни будут нужны и хотели ли они именно это в именно том же виде.

> Ах да, где там parity desclustered raid в btrs? очень полезная штука
> что бы не было bootleneck на одном из дисков.

А он в один диск сам по себе и не обязан упираться, внезапно. С его точки зрения - пишут вон те блоки. Блокам требуется такая-то схема. Оно кроит блоки под эту схему и раскидывает на девайсы где было "свободное место".

Откуда вытекает один забавный лулз: можно доткнуть хоть 1 стораж, и это даст +эн места. Без запар с размерами, числами девайсов и проч. Это просто +эн места. И допустим RAID1 в терминах этой штуки - "кинь 2 блока на 2 каких-нибудь разные девайса". Если там было 5 девайсов, очевидно, пустой 6-й позволит сделать больше таких комбо и наступает профит по месту. В сильно неидеальном случае может потребоваться ребаланс, но зачастую катит и просто воткнуть i++'й девайс и помметь +эн места. Если на остальных девайсах в сумме было свободного места как на этом - нет проблем.

Из такого же подхода следует и еще кой-что.
1) Никакого выравнивания по дискам нет.
2) Нет дисков с фокусированным парити.
3) Фигня типа бэда под одним из блоков не ведет к особым проблемам и на раз чинится. И оно даже знает какая копия верная, по чексумам.

> А вот в zfs есть, в md raid есть. в btrfs нету.

У btrfs как такового очень кастомный дизайн в этом всем - и сам по себе bottleneck такого плана там ниоткуда не следует. Как максимум там аллокатор еще не все фичи дизайна эффективно использует. И возможно что он мог бы делать какой-то load balancing умнее и информированнее, скажем, если RAID5 делать как block1+block2+blockXOR. Это можно пульнуть на вон те девайсы, а можно и на вон те, лишь бы там место еще было, и при этом вполне можно взять наименее занятые, допустим. И да, при этом нет сфокусированного тома где только parity. Есть группы блоков кидаемые по определенным правилам.

Это обеспечивает некоторые странности с сводобным местом, просто потому что ответ на вопрос о свободном месте зависит от "какую схему хранения этим блокам делать будем". Это априори неизвестно. То что сейчас оно как-бы фиксированными как бы уровнями ворочает - это просто максимально простая реализация, малость косящая под что-то привычное народу.

> В нормальных уровнях raid - 5/6 тоже "нюансы" ? ну ну.. это

Да, они не полностью доведены до ума. Как минимум write hole есть. Хотя большие головы грят что в принципе можно и заткнуть.

> предлагается пользовать mirror на объемах в 20P?

Спору нет, это не оптимально - и возможно на такой юзкейс его и не стоит здесь и сейчас. Но на этом юзкейсе мир не заканчивается.

> Опять потребности в колбасе нету?

Из тех кто активно пилил - видимо да. Это и правда достаточно нишевой случай. ИМХО логично что обладатели таких конфиг и должны пахать если им это надо и они полагают что это им может быть полезно.

> Так это и есть распределенная структура. С объемами на 10-20 P...

Семантика файловых операций никогда не делалась под распределенный параллельный доступ.

> хотя откуда от админов localhost такие объемы.
> Ничего что 1P это сейчас объем одной дисковой полки?

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

>> Если нечто в пингвине, это показатель определенных стандартов качества.
> Спасибо посмеялся. Пиши еще :-)

Ну как бы airlied вон на днях делом подкрепил, NAKнув какое-то барахло от интела. Мне нравится когда я вижу такое отношение к делу.

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

370. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (368), 08-Авг-20, 15:15 
> Не соглашусь насчет туфты, поюзав это на практике.

можно спросить - вы что нить кроме 1 диска в системе пользовали? ну так что бы 20-40-80 дисков было в NAS?
если нет - тогда давайте закрывать разговор. Вы все равно не поймете этих проблем.
Давайте я вам скажу - что journal checksum в ext4 (относительно не большой поток на самом то деле)
Может ощутимо тормозить всю систему.


> Пиара линуху более чем достаточно. И так поналезло маздайцев каких-то, пытающихся сделать виндопомойку.

Тут он и закончится. Наоборот начнется пиар того что лучше подходит, а линукс останется гикам.

> У корпораций? :D А на что уйдут? Винда не адаптируется, макось не серверная толком, бзды не от мира сего. На фуксию? Хипстеры устали дрова на игогошечке писать.

Когда-то так же говорили про GCC. Когда FSF устроил подлянку с GPL v3, резко появилось LLVM/Clang и gcc стал в догоняющих. Стоило начать отжимать бабло за немодифицированный busybox - так появился bsdl вариант.
Так и тут. Пока Linux удобен его будут использовать - благо дело в таких вещах это простая запускалка процессов, а все нужные либы/драйвера - или много платформеные или так или иначе есть под все платформы.
Пользователи даже не заметят разницы. Пока все упирается в хайп и то что проблемы не превышают допустимый порог.


> Вероятность что вторую (для особых параноиков i-ю) копию блока постигла та же участь - микроскопическая. И в этом месте теорвер уже за нас.

Давайте я вам расскажу - как умирали по 3-4 винта за раз, в полке из 40 дисков? была такая серия у WD - бах и 3 диска вылетело, и куда теорвер пойдет с такой теорией? вот declustered raid - как раз и помогал, а обычный raid6 не очень.


>Где-то это и вариант, но далеко не везде где используется Linux.

На localhost с одним винтом из домашней серии - да, наверно не вариант. Там хватит простых checksum.
В более нагруженных случаях - почему-то начинается упираться в ограничения этого подхода.

> Может быть, затем что это делает дохрена допущений относительно железа?

Затем что больший класс ошибок может быть отловлен. Но для localhost и так сойдет.
и места на винте это не занимает - правда требует спец форматирования винтов.


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

Спасибо посмеялся. Пиши еще. Как там поживает баг 12xxx когда вешался linux при IO?


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

А человечку было не до того что бы продумать. Надо было писать код. Знакомо.
Потом оказывается что работает оно хреново и малейшая переделка требует больших усилий.
Слово "Декомпозиция задачи" о чем-то говорит ?

> А его дизайн может в произвольную смесь уровней RAID и конверсию оных на лету?

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


>  И да, при этом нет сфокусированного тома где только parity. Есть группы блоков кидаемые по определенным правилам.

бедные клиенты.. file level raid это круто для понтов - но для реального масштаба плохо. объяснение этого весьма большое и лениво.


> Да, они не полностью доведены до ума. Как минимум write hole есть. Хотя большие головы грят что в принципе можно и заткнуть.

То есть или зеркалирование (которое жрет дофига места), или потери данных. Даааа - выбор прямо для продакшена.

> Спору нет, это не оптимально - и возможно на такой юзкейс его и не стоит здесь и сейчас. Но на этом юзкейсе мир не заканчивается.

Не спорю - для localhost это вполне себе решение под 2-3 винта.. Но вы правы - мир он более объемен.
Почему-то больше фирм которым нужен raid 5/6 - потому что 2 диска из 10 это нормальный overhead, а вот 1 из двух - это тривиально дорого. Когда нужно резервировать десятки.

Давайте на пальцах - работаете вы в фирме - нужно поставить NAS пусть на 20 дисков.. вам говорят вот есть raid5 и надежность но закрытое решение, или вы тупите свой btrfs - с mirror - и разницу в стоимости винтов - берем из вашего кармана (8 винтов хотя бы по 200 баксов - то есть 1600 долларов вы должны будете доплатить) - вы будет согласны выложить? Если не согласны - почему думаете что фирма должна это спонсировать?
Потом пойдем дальше - для лишних 8 винтов - лишнее электричество - его тоже надо кому-то оплатить.
Не желаете вычесть из зарплаты?
Лишнее охлаждение - цена новых кондиционеров + лишнее электричество туда?
Сколько там надо будет вычесть в итоге из зараплаты?

А если винтов не 20? а хотя бы 200? или 2000?
Может оказаться что нужно еще новое здание под серверную.. тоже надо бы оплатить.

И тут рядом решение - которое не требует всех таких затрат.. Я могу 100% предсказать какое возьмут ;-)


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

Куда налить? вот у меня с полки в сеть уходить 60Gbyte/s read/write (хотят 80 write/120 read - но пока вот так) - дальше не хватает PCIe даже на последних AMD.
Таких полок около 100 в кластере - каждая может выливать столько.
Куда вы говорите вылить терабайт в секунду? И сколько поток у Ютуба? Не подскажете почему вдруг он закупает электростанции что бы электричество подешевле иметь? наберите в поиске "google купил электростанцию" - вас ждет очень много открытий.

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

383. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Аноним (-), 10-Авг-20, 07:23 
> можно спросить - вы что нить кроме 1 диска в системе пользовали?
> ну так что бы 20-40-80 дисков было в NAS?

До пары десятков дисков собирал. Ну, работало. А чего ему не? Правда RAID1, конечно, а не RAID56. Хотя конечно можно как пох, выбрать самое глупое и проблемное действо и потом показательно корчиться с простреленной пяткой.

> если нет - тогда давайте закрывать разговор. Вы все равно не поймете этих проблем.

Я не утверждаю что btrfs - серебряная пуля на вообще все оказии и что это оптимально для ВСЕХ конфигураций и требований.

> Давайте я вам скажу - что journal checksum в ext4 (относительно не
> большой поток на самом то деле) Может ощутимо тормозить всю систему.

Может. И чексумы в btrfs - могут. Смотря по ситуации. Сколь-нибудь большие или странные конфиги всегда требуют к себе внимания и могут подкинуть странностей. И чего?

> Тут он и закончится. Наоборот начнется пиар того что лучше подходит, а
> линукс останется гикам.

Этот мир не настолько черно-белый и на HPC имени нвидии он вообще совсем не заканчивается. Так что вы имхо не дождетесь выполнения своего предсказания.

> Когда-то так же говорили про GCC. Когда FSF устроил подлянку с GPL
> v3, резко появилось LLVM/Clang и gcc стал в догоняющих.

Я б не назвал его догоняющим. Ну и в линухе "подлянка" с GPL была - ВНЕЗАПНО - изначально. Но вот проприенТарные бцды народу что-то вштыривали меньше. И поэтому сейчас остались только у самых жадных и наглых из жлоборасов. Остальным оказалось проще и дешевле делиться. Ну а смысл зажимать полтора патча? Они конкурентам погоды не делают. А жаба ради жабы - большинство более-менее живого бизнеса достаточно вменяемо чтобы преодолеть антипаттерны ради антипаттернов.

> Стоило начать отжимать бабло за немодифицированный busybox - так появился bsdl вариант.

...который как и BSD недоразвит и даром никому не вперся, проще gpl tarball выложить чем долбаться с кучей более хитрых технических проблем. Ну будет в нем еще и это. А какой кому профит с зажатого сорца бизибокса? :)

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

Красивая теория. Жаль что не имеет особого отношения к практике.

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

Хайп, видите ли, не на ровном месте появился. А потому что это единственная штука на глобусе которая сумела в кучу убер фич и при этом не скатиться в глюкало.

> Давайте я вам расскажу - как умирали по 3-4 винта за раз,
> в полке из 40 дисков? была такая серия у WD -

Да и у сигейта веселые 7200.11 были.

> бах и 3 диска вылетело, и куда теорвер пойдет с такой
> теорией? вот declustered raid - как раз и помогал, а обычный raid6 не очень.

Для особо странных случаев btrfs ща умеет N копий делать. Ну, как RAID1, только блок не 2 раза дублируется а 3 или 4. Могли бы и больше - просто никто не просил.

> На localhost с одним винтом из домашней серии - да, наверно не
> вариант. Там хватит простых checksum.

А можно и не с одним и даже не для локалхоста. У мордокниги например были прикольные баги вида "если файл более 20 терабайтов, в полнолуние високосного года ведьмы напускают проклятье".

> В более нагруженных случаях - почему-то начинается упираться в ограничения этого подхода.

У разных подходов есть свои плюсы и минусы. Этот мир не заканчивается на убер-энтерпрайзных переростках.

> Затем что больший класс ошибок может быть отловлен. Но для localhost и так сойдет.

Да и не только для локалхост. А распределенным суперструктурам бывает и вообще до лампочки что там с локалхостом на той ноде и почему именно оно кривой блок выгрузило. Запросят с других, до тех пор пока правильный не приедет. И в эту чудную формулу опять же ваши мегахрени не входят, можно такое из ширпотреба сделать. Что гугл и практикует. Ну а вы их никогда не законкурируете, у вас при попытке что-то такое сделать -ENOBUCKS случится в момент.

> и места на винте это не занимает - правда требует спец форматирования винтов.

Могу себе представить какая будет радость если это все же хренакнется. Небось пара лаб на всю планету поднять это смогут. За пару вагонов бабла - за то что они это спец форматирование разреверсили, видите ли :)

> Спасибо посмеялся. Пиши еще. Как там поживает баг 12xxx когда вешался linux при IO?

Закрыт как пофикшеный. ЧСХ много такого и правда починили. Да и не IO это был, а взаимоотношения IO <-> cache в специфичных ситуациях.

> А человечку было не до того что бы продумать. Надо было писать код. Знакомо.

Там как раз судя по виду этой штуки неплохо подумали до того как код писать. Некоторые вещи может и не идеально - но у других не получилось и так.

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

Однако со временем причесали, обезглючили, оптимизнули, работать стало уже довольно прилично, так что ок фб, зюзе и даже фидоре вон.

> Слово "Декомпозиция задачи" о чем-то говорит ?

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

Ну вот в линухе поскрипели, побухтели и попросили реюзать максимум из того что могут поюзать. И оно таки реюзает facilities ядра везде где может. От ядерных воркеров до алгоритмов чексум и кода RAID. А то что этот код юзается довольно креативно и поэтому это не вообще весь уровень - ну да. Так обычный блочный RAID не больно то и сконвертишь на лету во что-то другое малой кровью...

> Может. Но зачем? Просто ради понтов?

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

> потребности в этой колбасе нету :-)

Кому как, кому как. Я бы с удовольствием назначил разные уровни разным файликам. Кому и тройной резерв не жалко, типа моих проектов, а кому и 1 копии хватит, типа одноразовой буиты "посмотрел, стер, вымыл руки с мылом".

> Надеюсь вы помните такой факт в криптографии что последовательное шифрование разными
> алгоритмами не увеличивает стойкость защиты а может даже ухудшать? С рейдами
> похожая ситуация.

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

> бедные клиенты.. file level raid это круто для понтов - но для
> реального масштаба плохо. объяснение этого весьма большое и лениво.

Для начала - я вот это хочу для лично себя, например. И если нечто так не умеет, это сразу -10 к моим симпатиям данной технологии. Если кто еще не понял, я вообще совсем не намерен быть сапожником без сапог. И считаю что клевые технологии должны работать в том числе и на лично мое благо. Иначе не такие уж они и клевые. Какое мне дело до твоих клиентов? А моим клиентам, внезапно, DUP на sd/emmc карте одноплатника - надежность здорово улучшает. И не то чтобы кто-то собирается ставить дисковую полку для загрузки штуки с пачку сигарет размером, это бред.

> То есть или зеркалирование (которое жрет дофига места), или потери данных. Даааа
> - выбор прямо для продакшена.

Еще умеет DUP на однодисковой конфиге. По своему прикольно. Я это на одноплатниках втулил, так что при нефатальных развалах sd/emmc задооооолго до фактического отказа early warning получается. А при разовых взглюках типа слета питания и продолба блока флеша на записи оно это тупо починит в фоне из второй копии - и все работает как батарейка энержайзер. И теорвер таки очень сильно за меня - с EXT4, я, видите ли, вообще совсем проигрываю если проблемный блок попал под какой-нибудь libc6. Система после этого просто не может выйти на режим. Ну и все, приплыли. А не прикольно теорверу проигрывать то, особенно с 1 сбойного блока раз в дофига лет.

Юзкейсы разные бывают. И да, btrfs не монструозный, ему и на такой конфиге ОК. Даже на 1-ядерном cortex A7 с 256-512 рамы нормально себя чувствует. Это вам не ZFS.

> Не спорю - для localhost это вполне себе решение под 2-3 винта..

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

> из 10 это нормальный overhead, а вот 1 из двух - это тривиально дорого. Когда
> нужно резервировать десятки.

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

> Давайте на пальцах - работаете вы в фирме - нужно поставить NAS пусть на 20 дисков..

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

> Сколько там надо будет вычесть в итоге из зараплаты?

Сферические блабла в вакууме.

> А если винтов не 20? а хотя бы 200? или 2000?

Да ктулху меня упаси от такого инженерного бреда как 1 стораж на 2000 винтов. Там 99.9% что архитекта этого булшита надо было выпереть с волчьим билетом, и давно. Умные головы говорят что лобовые подходы не всегда наилучшие. И если все приходит к вот такому - это именно тот самый случай.

> И тут рядом решение - которое не требует всех таких затрат.. Я
> могу 100% предсказать какое возьмут ;-)

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

> Куда налить?

Клиентам, Карл! Ну вот в случае гугли - видео всей планете льют, например. Да и не только видео.

> вот у меня с полки в сеть уходить 60Gbyte/s read/write (хотят 80 write/120 read
> - но пока вот так) - дальше не хватает PCIe даже на последних AMD.

Что я там говорил про то что выше энного порога - хренакс? А гугол добавит еще пачку серверов и у них будет ровно столько гигабайтов сколько нужно для того чтобы весь глобус мог смотреть видео, задавать глупые вопросы, ... - такое масштабируется по числу подцепленых систем, однако. Там нет верхнего лимита. Лучший bottleneck - это его отсутствие, на уровне дизайна.

> Таких полок около 100 в кластере - каждая может выливать столько.
> Куда вы говорите вылить терабайт в секунду? И сколько поток у Ютуба?

Около 30% трафика интернета, чтоли. А вы ваш терабайт в секунду, натурально, куда вылить то сможете в таком объеме? На соседний локалхост? Или у вас каналы по всей планете есть? А может, у вас таки и тут дурь с масштабированием? Потому что ну вот допустим юзерям видео налить таким макаром уже не получится на всю толпу. А вот распределенные структуры в этом плане заметно более сбалансированные вещицы. Так что ценность понта сферическими терабайтами в вакууме вызывает у меня определенные сомнения.

> Не подскажете почему вдруг он закупает электростанции что бы электричество подешевле иметь?

Потому что когда у вас дофига датацентров по всей планете - их содержание что-то стоит.

> наберите в поиске "google купил электростанцию" - вас ждет очень много открытий.

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

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

304. "Предложение по блокировке драйверов-прослоек, предоставляющи..."  +/
Сообщение от Я (??), 06-Авг-20, 10:26 
Nvidia has you..
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

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

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




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

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