Линус Торвальдс обвинил разработчиков FreeBSD в некомпетентности

> Но если он и впредь будет вести себя как не как джентльмен, (грубить девушкам в дамской уборной),

Девушки в дамской уборной это разработчики BSD, я правильно понял?

> то джентльмены вправе требовать о недопущении г-на Линуса в благородное собрание OpenSource (linux.org.ru).

Ну под анонимусом то можно.

>> это специфический лист для разработчиков.

> Они сделали его закрытым (только по приглашению лейтенантов Линуса)?
> Убрали архивы с веба?

>> молодежи с неустоявшейся психикой (вот причем тут "красноглазый")
>> делать там реально нечего.

> Где это написано в полиси мейллиста? При входе требуют предъявлять Age
> ID?

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

аналогия надеюсь понятна

>> употребляют его все.

> Вызывающе неверная информация.

можете ли вы отличить мат от не-мата и от иностранного слова ? и каким образом ? потому что знаете что есть мат а значит используете его. матершинные слова есть в вашем мозгу и то что вы говорите "дорогой иван иванович ну зачем вы меня не позвали я бы сам все сделал" а про себя думаете "вот дол****б, это же надо умудриться втиснуть sdram в ddr" ничего не меняет


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

в остальном полностью поддерживаю гика

> Happy New Kernel! 2.6.16.10

Happy new FreeBSD 7.0-CURRENT! 26.04.2006

> Happy new FreeBSD 7.0-CURRENT! 26.04.2006
Happy New Kernel! 2.6.16.11

)

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

natd появился _позже_ ipnat в ipfilter. Впрочем, некомпетентным идиотам простительно не углубляться в предмет, о котором они с таким апломбом рассуждают.

Про "дикие" тормоза: ну и где ты словил эти "дикие" тормоза, болезный? natd в юзерпейсе через divert - красивое решение. Желающим выиграть три процента никто не запрещал переходить на ipnat.

//Loseki

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

>Обосновать можешь? Чем ему еще заниматься, когда приемная сторона тормозит, а мы уже буферы заполнили, все данные подготовили... Только и остается, что сидеть и ждать.

>> Приложение вызвало sendfile(), и когда вызов завершен, все данные уже отправлены

>А пока длится вызов, приложение спит? Так блин, "если приложение засыпает между посылками, то это плохо" ;)

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

Проведите тест dd if=/dev/zero of=/tmp/file bs=1k count=1000 и тоже самое для bs=4k

10240000 bytes (10 MB) copied, 0.01086 seconds, 943 MB/s

40960000 bytes (41 MB) copied, 0.016113 seconds, 2.5 GB/s

Что называется, почувствуйте разницу.

>> Вот это правильных подход.

>Это лишь частный случай передачи данных, не предлагаешь же ты всегда сперва готовить файл, а потом его слать? И если ты не знал, во FreeBSD есть sendfile(). Очень эффективная и быстрая zero_copy реализация.

Я показываю, что sendfile() пострен по принципу "положи это туда", а не "возьми оттуда и положи туда", по которому построены сокеты вообще и zero-copy sockets во freebsd в частности. vmsplice() позволяет "положить это туда".

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

>Не путай божий дар с яичницей.

Мощный аргумент.

>> Если вы заснули на записи в сокет, это означает, что вы не можете вычитывать данные из файла (как пример).

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

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

>Это ты описываешь проблемы aio и vmsplice()? Да, там именно так и есть, необходима постоянная синхронизация.

Это я описываю проблемы сокетов вообще и zero-copy sockets из freebsd в частности.

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

>Чую, разжевывать необходимо, самостоятельно прочитать man zero_copy люди не в состоянии...

Люди выше привели вырезку из мана, где говорится, что aio completion вообще нет для zero-copy sockets, т.е. этот хак как таковой без COW не работает :)

>baka-kun *** (*) (24.04.2006 17:04:18)

> дорогой мой

Вряд ли именно Ваш.

> аналогия надеюсь понятна

Аналогия не верна. Меня покоробило не слово "идиот" (почти невинное), а хамский тон. И, умоляю, не надо говорить, что в книжках тоже хамят. Разница, надеюсь, понятна. Впрочем, с гиком мы практически договорились - Линусу не повезло стать инженером, степень известности которого сильно превышает его способность соответствовать ей.

> ничего не меняет

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

> нечего нос воротить от реалий жизни

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

svu, да ты оказывается моралист ещё тот :)

кстати, "жалкий инженеришка" - это совсем не хамское выражение, а "идиот" хамское? или это на svu на ЛОРе можно бросацца какашками, а Торвальдсу в lklm - уже нет?

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

вот что смешно - сами раработчики БЗДи не обиделись почему-то (странно, да?), а вот толпа моралистов возбудилась сверх всякой меры :)

s/это на svu на ЛОРе/это svu на ЛОРе

> svu, да ты оказывается моралист ещё тот :)

Да, бывает:) Наверное, старость;)

> или это на svu на ЛОРе можно бросацца какашками, а Торвальдсу в lklm - уже нет?

Если Вы осилите весь тред:), то посередине я где-то уже высказывался в духе того, что никому нельзя. А L.T. просто _особенно_ нельзя;)

Да, в оригинале было "невоздержанный на язык" (констатация факта). Ничего про "жалкого" там не было. Специально проверил;)

>посередине я где-то уже высказывался в духе того, что никому нельзя. А L.T. просто _особенно_ нельзя;)

да асилил ещё вчера :).

здесь вот ведь какое дело - никому нельзя, но все бросаются :). и линуксоиды, и БЗДуны, и Торвальдс и Тео, и не только они - то есть, бросание какашками - это данность, в которую вписывается даже моралист svu :)

geek, имхо, в общем-то прав: Линус сам решает, какие ему выбирать (или невыбирать) выражения, все остальные решают как им реагировать.

Тео, тоже лидер проекта, и все те обязательства, которые торжественно вручают лидеру - ему тоже навязаны, как и Торвальдсу. Один плевал на них, и другой плюёт. имхо - это их личное дело. они при вступлении в должность присягу на posix api не давали, разговаривать лексиконом института благородных девиц не обещали... один говорит, что линукс помойка и фуфло, другой назвал разработчиков БЗДи идиотами. квиты? :)

З.Ы. насколько помню, за весь тред ни разу не встретил слова "толерантность". наверное оно не знакомо присуствующим... а жаль. толеранстность, в отличие от морализаторства, облегчает общение, а не усложняет его.

>Да, в оригинале было "невоздержанный на язык" (констатация факта)

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

> квиты?

Ну не квитости ж дело, ну как же Вы не понимаете?...;)

> бросание какашками - это данность, в которую вписывается даже моралист svu :)

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

> З.Ы. насколько помню, за весь тред ни разу не встретил слова "толерантность". наверное оно не знакомо присуствующим... а жаль. толеранстность, в отличие от морализаторства, облегчает общение, а не усложняет его.

Согласен абсолютно. Вопрос в том, где толерантность оборачивается всепрощением и вседозволенностью.

Ок, за "инженеришку" готов ответить. Впрочем, выше я объяснил, что означает это слово: жесткое и печальное несоответствие исторической значимости личности и уровня ее сознания. Возможно, русское слово "выскочка" (если воспринимать его обобщенно) будет более соответствовать . Готов с извинениями s/инженеришка/выскочка/ ;)

>Ок, за "инженеришку" готов ответить

передо мной, что ли? :). не надо - личное мнение svu о Торвальдсе ко мне никакого отношения не имеет :). перед Торвальдсом? ну можно попробовать, но что-то мне подсказывает, что даже если бы он узнал о такой его характеристике - вряд ли это могло бы его обидеть :)

>Вопрос в том, где толерантность оборачивается всепрощением и вседозволенностью.

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

если Торвальдс считает, что COW в общем-то плохая технология, даже не смотря на то, что когда-то при каких-то условиях разработчики БЗДи не нашли лучшей, и эта кое-как работала, то назвать разработчиков БСДи идиотами вполне может соответствовать его нравственным принципам, хотя мораль такие высказывания осуждает. Если он считает, что код идиотский, почему бы не назвать разработчика кода идиотом? :). это ж правда, а на правду глупо обижаться - даже если правда выражена в резкой форме :)

другое дело, если бы он ляпнул это неразобравшись в ситуации - тогда идиотом следовало бы назвать его, и ему тоже не на что было бы обижаться :)

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

и напоследок ещё раз повторю: разработчики БСД не обиделись :). и правильно сделали :). и по существу не возражали :)

> на этот вопрос, имхо, каждый отвечает сам.

Увы (или, пожалуй, к счастью), не всегда. Крайний случай, когда проявление толерантности было бы неуместно - Нюрнбергский процесс. В случае абсолютной толерантности союзничков, его бы не было. Так что таки есть общественно-принятые нормы толерантности. И области, которые можно "статистически" назвать вседозволенностью. Например, толерантность к ксенофобии у меня отсутствует как класс - и я твердо убежден в том, что ей тут не место.

> мораль возникла потому, что исчезла нравственность...

Красиво сказано, но как-то бездоказательно. Особенно если вспомнить, что Дидро в Энциклопедии просто замкнул эти понятия друг на друга (не дав определения ни одному из них;). Можно обосновать и расширить?

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

Неужели Вы сочли меня обидившимся (при том что я к разработке BSD никак не отношусь?;) Вы ж понимаете, мои рассуждения - из серии "что может себе позволить человек (в таком положении), чего не может". Разумеется, оно все "ИМХО".

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

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

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

>Красиво сказано, но как-то бездоказательно. Особенно если вспомнить, что Дидро в Энциклопедии просто замкнул эти понятия друг на друга (не дав определения ни одному из них;). Можно обосновать и расширить?

вкратце можно.

моральные нормы - это правила поведения, установленные общественным мнением и предписываемые к исполнению членами общества. в случае нарушения этих правил поведения, к нарушителю применяются санкции в виде общественного остракизма (что мы видим в нашем случае - конкретно Вы, svu, высказываете осуждение действий Торвальдса по нарушению норм вежливости, кой-кто даже с линукса уходить собрался :).

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

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

>Неужели Вы сочли меня обидившимся (при том что я к разработке BSD никак не отношусь?;)

да нет, конечно :). но многие другие учасники треда, тоже врядли имеющие отношение к разработке БСД таки обиделись :)

>Вы ж понимаете, мои рассуждения - из серии "что может себе позволить человек (в таком положении), чего не может"

оч. хорошо понимаю :). и моё имхо состоит в том, что люди в нашем с Вами положении (праздно общающиеся на ЛОРе) врядли могут позволить себе судить человека, находящегося в другом положении :)

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

> На этом сказочке конец, а кто слушал молодец, дядям kan и AVL пусть подарят леденец :)

> Детский сад.

Зач0т. Однозначно.

> Я же написал, что засыпание между посылкой 1кб и засыпание при посылке 1гб - разные вещи.

Или кто-то тебя заставляет слать по 1К, или кто-то не понимает, что write(fd,buf,N*M*1024*1024) -- это вполне нормально. Одно из двух, поскольку третий вариант (что ты -- тролль) я с ходу отметаю. ;)

> vmsplice() позволяет "положить это туда".

Позволяет. Требует синхронизации. В процессе обсуждения, как уберечь буфер от перезаписи "на лету" (пока ядро еще отправляет из него данные), прозвучало предложение, помимо очевидно необходимых в подобном асинхронном механизме флагов/семафоров/etc, выставлять еще и read-only, как во FreeBSD в zero_copy_sockets. В ответ Линус вспылил, обозвал посторонних людей, и договорился до того, что предложил лучше пожертвовать надежностью и работоспособностью, чем производительностью.

Линус минимум дважды неправ. Это мое личное мнение. Во-первых, нагрубил. Во-вторых, система не имеет права надеяться, что все приложения идеальны, поэтому ядро (и окружение в целом) должно максимально изолировать свои данные от пользовательских процессов, и уж точно не позволять in-flight изменение ядерных страниц памяти. Как, например, некоторые реализации libc имеют защиту от double free и от попытки free() по указателю, который не был получен из malloc(). Причем реакцией может быть как warning, так и error, на усмотрение администратора.

В данном случае Линус предлагает забить на потенциальную ошибку приложения, то есть о ней может узнать _только_ приемная сторона по кривым данным (а может и не узнать, если не умеет проверить). Хотя, поставив на буфер read-only, ты _точно_ получишь исключение, когда приложение тупит. А дальше ты можешь а) скрыть ошибку, сделав COW, тогда и данные уйдут в целости, и приложение продолжит работу, немного потеряв в производительности; или б) среагировать на это как на критическую ошибку, и прибить приложение, или дать ему знать о проблеме.

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

> "вы получаете накладные расходы из-за постоянных проверок" ... Это я описываю проблемы сокетов вообще и zero-copy sockets из freebsd в частности.

Это _НЕ_ является проблемой сокетов вообще и zero_copy_sockets в частности. Необходимость проверок, освободился ли буфер или нет, касается _только_ асинхронных механизмов.

>> Чую, разжевывать необходимо, самостоятельно прочитать man zero_copy люди не в состоянии...

> Люди выше привели вырезку из мана, где говорится, что aio completion вообще нет для zero-copy sockets, т.е. этот хак как таковой без COW не работает :)

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

Да, "The socket(2) API does not really give the user any indication of when his data has actually been sent over the wire, or when the data has been freed from kernel buffers." И не потому, что "aio completion вообще нет": сам механизм сокетов по сути синхронный, когда места в буфере сокета (SO_SNDBUF) недостаточно, write(2) или send(2) блокируются, по выходу из сискола приложение готовит следующие данные, а ядро досылает остатки буфера сокета.

В случае zero_copy_sockets никто не стал изобретать лишних сущностей, используется стандартный api, только копирования в ядерные буферы не происходит, а берется пользовательская страница. Поэтому для предотвращения COW надо готовить данные для следующего write(2) в другом буфере. И если бы "люди выше" осилили параграф:

"From an application standpoint, the best way to guarantee that the data has been sent out over the wire and freed by the kernel (for TCP-based sockets) is to set a socket buffer size (see the SO_SNDBUF socket option in the setsockopt(2) manual page) appropriate for the application and network environment and then make sure you have sent out twice as much data as the socket buffer size before reusing a buffer."

то без проблем написали бы приложение, гарантированно не приводящее к COW.

---

char buf[2][SNDBUF_SIZE*2]; /* два буфера достаточно. если мы не можем готовить к передаче более SNDBUF_SIZE*2 за раз, то заводим массив с таким количеством элементов, чтобы суммарный размер превышал SNDBUF_SIZE*2+объем_блока_данных */

int i = 0;

while (...) {

/* Готовим данные к отправке в buf[i] */

write(fd, buf[i], SNDBUF_SIZE*2);

i ^= 1;

/* Всё, в следующую итерацию мы _гарантированно_ будем готовить данные в свободном буфере, и не вызовем copy-on-write, поскольку write(2) вернется только тогда, когда к отправке останется <=SNDBUF байт.

На данный момент ядро уже освободило buf[i] */

}

---

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

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

Лично я проблем с natd у FreeBSD 4.8 не замечал.

> а затем, через много лет, додумались засунуть его наконец в ядро, ядреный libalias, в дырявой 6.0. Почему большому бздуну Тео можно срать на Linux по поводу и без повода, а Линусу за дело БЗДэму пнуть нельзя?

Потому что у Тео есть pf(4). :)

> anonymous (*) (25.04.2006 7:44:23)

Ну и перечитайте историю. Там в NetBSD один чувак есть или был, который любит ламеров игнорировать, и ему не нравилось, что Тео ламерам говорил, что они ламеры. Проблема давно решена -- в OpenBSD ламерам открыто говорят, что они ламеры. Поверьте, так намного легче. Вот интересное с ним интервью, которое очень отчётливо объясняет проблему в NetBSD: http://www.theage.com.au/articles/2004/10/07/1097089476287.html

>и напоследок ещё раз повторю: разработчики БСД не обиделись :). и правильно сделали :). и по существу не возражали :)

"Собака лает --- караван идет".... (с)

>> Я же написал, что засыпание между посылкой 1кб и засыпание при посылке 1гб - разные вещи.

>Или кто-то тебя заставляет слать по 1К, или кто-то не понимает, что write(fd,buf,N*M*1024*1024) -- это вполне нормально. Одно из двух, поскольку третий вариант (что ты -- тролль) я с ходу отметаю. ;)

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

вычитать 1кб/1мб/... в буфер, записать буфер в сокет.

В то время как подход "положи это туда", sendfile() проще говоря, позволяет сразу отправлять VFS страницы в сеть.

Вот в чем дело, а не в размере буфера.

>> vmsplice() позволяет "положить это туда".

>Позволяет. Требует синхронизации. В процессе обсуждения, как уберечь буфер от перезаписи "на лету" (пока ядро еще отправляет из него данные), прозвучало предложение, помимо очевидно необходимых в подобном асинхронном механизме флагов/семафоров/etc, выставлять еще и read-only, как во FreeBSD в zero_copy_sockets. В ответ Линус вспылил, обозвал посторонних людей, и договорился до того, что предложил лучше пожертвовать надежностью и работоспособностью, чем производительностью.

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

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

>Во-вторых, система не имеет права надеяться, что все приложения идеальны, поэтому ядро (и окружение в целом) должно максимально изолировать свои данные от пользовательских процессов, и уж точно не позволять in-flight изменение ядерных страниц памяти. Как, например, некоторые реализации libc имеют защиту от double free и от попытки free() по указателю, который не был получен из malloc(). Причем реакцией может быть как warning, так и error, на усмотрение администратора.

>В данном случае Линус предлагает забить на потенциальную ошибку приложения, то есть о ней может узнать _только_ приемная сторона по кривым данным (а может и не узнать, если не умеет проверить). Хотя, поставив на буфер read-only, ты _точно_ получишь исключение, когда приложение тупит. А дальше ты можешь а) скрыть ошибку, сделав COW, тогда и данные уйдут в целости, и приложение продолжит работу, немного потеряв в производительности; или б) среагировать на это как на критическую ошибку, и прибить приложение, или дать ему знать о проблеме.

>Когда в погоне за "свистелками" и производительность забывают о надежности, остается только грустно вздыхать.

Реализации vmsplice() для пользовательских страниц и сетевых буферов еще не существует, и не факт, что в ближайшее время появится. Но сам подход vmsplice() другой, нежели COW хак в FreeBSD.

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

Линус говорит как раз об этом. Не о COW, а о хаке с VM для zero-copy sockets. И именно из-за того, что _хак_ кривой, требуется COW.

> Люди выше привели вырезку из мана, где говорится, что aio completion вообще нет для zero-copy sockets, т.е. этот хак как таковой без COW не работает :)

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

>Да, "The socket(2) API does not really give the user any indication of when his data has actually been sent over the wire, or when the data has been freed from kernel buffers." И не потому, что "aio completion вообще нет": сам механизм сокетов по сути синхронный, когда места в буфере сокета (SO_SNDBUF) недостаточно, write(2) или send(2) блокируются, по выходу из сискола приложение готовит следующие данные, а ядро досылает остатки буфера сокета.

Вот здесь и кроется основная проблема!

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

Если выставлять размер буфера сокета для посылки равным посылаемым данным или меньше, что вы предлагаете ниже, то производительность будет чрезвычайно мала из-за невозможности объединять пакеты, TSO и т.п. Где вы видели высокопроизводительный сервер с 4k/16k и подобными размерами sndbuf? 2mb - хороший размер, но количество tlb flush и накладных для хака VM при этом _очень_ большие (и растут эти накладные расходы отнюдь не линейно с ростом буфера). Более того, когда создавался этот механизм, такие объемы памяти никогда не использовались для sndbuf, т.к. было 10мбит в лучшем случае...

Отсюда мы можем сделать вывод, что VM хак, необходимый для работы zero-copy sockets в современном мире просто не пригоден.

baka-kun *** (*) (25.04.2006 20:51:31)

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

Странно... До этого не получилось от анонимуса
добавить, а сейчас попробовал - добавилось. :)
Придётся заново писать...

> помимо очевидно необходимых в подобном асинхронном
> механизме флагов/семафоров/etc, выставлять еще и
> read-only, как во FreeBSD в zero_copy_sockets.
Вот если бы во FreeBSD было "еще и read-only", то так бы
он не ругнулся. Хотя он и сказал, что даже подход
"еще и read-only" он считает не приемлемым. Но там-то
только COW, а остального нет.

> Во-вторых, система не имеет права надеяться, что все
> приложения идеальны, поэтому ядро (и окружение в
> целом) должно максимально изолировать свои данные от
> пользовательских процессов, и уж точно не позволять
> in-flight изменение ядерных страниц памяти.
А какая разница, если эти страницы всё равно от
пользователя? Он мог их точно так же и неправельно
сформировать. Это как use-after-free, например. Что,
предложишь теперь все проги с dmalloc линковать?
Сделали тебе SIGSEGV при попытке обращения к нулевому
адресу - скажи спасибо, ведь могло и этого не быть.
Просто это не приводит к накладным расходам, вот и
сделали.

> Как, например, некоторые реализации libc имеют защиту
> от double free и от попытки free() по указателю, который
> не был получен из malloc().
Именно что некоторые, и, если речь идёт о новых glibc,
то там далеко не все случаи отлавливаются. Есть
только простейшие проверки, те, что не влияют на
производительность опять же. А от use-after-free ни
одна реализация не защищает. Для этого есть dmalloc,
но это уже средство отладки. Точно так же и
проверку на изменение ещё не отправленных страниц
можно запихнуть в valgrind - и отлаживайся наздоровье.

> Причем реакцией может быть как warning, так и error, на
> усмотрение администратора.
На этапе отладки - сколько угодно. Только речь шла
именно про CoW. Если реакцией является не warning и не
error, а COW, тогда что?

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

> А дальше ты можешь а) скрыть ошибку, сделав COW
Вот на это он и ругнулся. Это - худший вариант, и
он имеет место быть в FreeBSD.

> среагировать на это как на критическую ошибку, и
> прибить приложение, или дать ему знать о проблеме.
На этапе отладки - да. На этапе эксплуатации от
этого пользы уже не много, а в производительности
потеряют и те проги, которые подобные ошибки не
содержат, т.к. для них тоже будет тратиться время
на пометку сраниц как read-only.
Хотя вообще, Линус сказал, что пользователь должен
иметь возможность модифицировать буффер после
отправки в ядро, и что ничего плохого в этом нет.
Я так не считаю, но это уже другая история.
Разработчики отладочных средств (valgrind) пусть сами
решают, нужно ли добавлять такую проверку, или нет.

> Когда в погоне за "свистелками" и производительность
> забывают о надежности, остается только грустно
> вздыхать.
Надёжное ядро должно надёжно защищать одни процессы от
ошибок в *других* процессах, но никак не в самих себе. :)

продолжение следует...

> Эти "люди выше", как и ты, тоже "ниасилили"
> следующий за цитируемым параграф.
Перестаём судить о других по себе, ОК? :)
Этот параграф мне было стыдно даже здесь цитировать
на самом деле. :)

> И если бы "люди выше" осилили параграф:
то их мнение о фряхе ухудшилось бы ещё в 20 раз, ты
это хотел сказать? :)

> "From an application standpoint, the best way to guarantee that
> the data has been sent out over the wire and freed by the
> kernel (for TCP-based sockets)
Отлично! А если не TCP-based sockets? Там ведь ясно
сказано, что некоторым протоколам, таким как TCP,
буффер отправки приходится держать в памяти вовсе не
до физической его отправки, а до прихода подтверждения
с принимающей стороны. Это нужно для того, чтобы в
случае ошибки иметь возможность осуществить retransmit.
Таким образом, почему же трюк с двумя буфферами
работает? Читаем внимательно, ага, они подгоняют
размер TCP-window под размер буффера сокета. Гениально.
Читаем ещё дальше и видим ещё кучу хаков. И видим,
что на приём этот механизм вообще работает только
на одной сетевухе в мире и то только с
модифицированной прошивкой...

> то без проблем написали бы приложение,
> гарантированно не приводящее к COW.
Только во FreeBSD и только при работе с TCP. Не вариант.
Кое-кто хочет более портируемые приложения писать.
А это - эвристика и куча хаков. В здравом уме делать
такое никто не будет, собственно по этому её и
отключили.

>> И почему глобальная переменная, в этом случае, -
>> лучше?
> По-моему очевидно:
Не поддавайтесь на провокации. :) Теперь вас хотят
заставить доказывать, что передавать аргументы через
глобальные переменные лучше, чем через параметры, а
что потом придумают? :)
Мне кажется, что то, как там передаётся указатель на
current thread, ничто по сравнению с грандиозной разницей
в читаемости кода, а так же с вещами типа
#ifdef MAC
и прочим бредом.

> Линусу не повезло стать инженером, степень известности
> которого сильно превышает его способность
> соответствовать ей.
Вы что-то заговариваетесь. :) "стать инженером" ...
"его способность соответствовать" - а какая у
*инженера* должна быть способность соответствовать
своей известности? Правельно - хорошие знания в сфере
своей инженерной деятельности. И в чём вы считаете
эту его способность недостаточной?

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

> И да минет меня чаша сия;)
Минует, не беспокойтесь. :) Свою роль он получил по
праву и полностью её оправдывает - не каждому такое
дано. Но и роль слэшдотовского идола вас скорее всего
тоже минует, хотя, судя по вашим предыдущим
комментариям "если бы достаточное к-во людей считало
бы меня таким-то, то мне всерьёз бы пришлось
задуматься над поведением", вы бы её как раз приняли,
а не пытались бы её всеми способами опровергнуть. :)

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

По сети _в_любом_ случае передаются маленькие блоки, не превышающие MTU. В случае простых сокетов данные передаются из буферов nmb, куда копируются из пользовательских, при zero_copy происходит DMA непосредственно из пользовательского буфера, sendfile() передает напрямую из буферов FS.

Никто не спорит, что sendfile() очень выгоден для передачи уже готовых файлов на fs. Хотелось бы использовать подобную технику для передачи произвольных данных, созданных в приложении. Во FreeBSD сделали zero_copy_sockets. Они работают, и дают реальное преимущество корректно написанным приложениям. В Linux пока ничего подобного нет:

> Реализации vmsplice() для пользовательских страниц и сетевых буферов еще не существует, и не факт, что в ближайшее время появится.

Угу. Зато всегда легко ругать чужую работающую реализацию.

> Но сам подход vmsplice() другой, нежели COW хак в FreeBSD.

Еще раз: для работы zero_copy_sockets COW _НЕ_ нужен, более того _вреден_. COW применяется только как защита буфера от некорректных/старых приложений.

При этом последние продолжают работать без всякого переписывания и/или пересборки, не получая преимуществ, но и не ломаясь. Для них случается COW, когда происходит такое редкое стечение обстоятельств: во write() передали буфер, который а) выровнен на границу страницы, б) кратен странице в размере. Во всех прочих случаях для legacy приложений используются старые-добрые _не_ zero-copy сокеты.

> Надеюсь все понимают, что проблема не в COW, а в манипулировании страницами пользовательского процесса

Понимают. И Линус прекрасно понимает, что ему не обойтись без расшаривания пользовательской страницы с ядром, если действительно необходимо _zero_-copy. То есть zero-copy _НЕВОЗМОЖНО_ реализовать без "манипулировании страницами пользовательского процесса".

> И именно из-за того, что _хак_ кривой, требуется COW.

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

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

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

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

Нет. Ниже я предлагаю именно то, что написано в man -- повторно использовать буферы только после отправки минимум двух размеров буфера сокета. Такое поведение _гаранированно_ предотвращает COW.

> Более того, когда создавался этот механизм, такие объемы памяти никогда не использовались для sndbuf, т.к. было 10мбит в лучшем случае...

Этот механизм (zero_copy_sockets) изначально создавался для гигабитных сетей, где можно использовать джамбо фреймы, и где даже одно копирование буфера сказывается на производительности.

> Отсюда мы можем сделать вывод...

Отсюда можно сделать вывод, что ты рассуждаешь чисто теоретически, при этом не зная деталей ни теории, ни практической реализации. Я, в отличии от "теоретиков с ЛОРа", это всё прощупал своими руками.

>> Надеюсь все понимают, что проблема не в COW, а в манипулировании страницами пользовательского процесса

>Понимают. И Линус прекрасно понимает, что ему не обойтись без расшаривания пользовательской страницы с ядром, если действительно необходимо _zero_-copy. То есть zero-copy _НЕВОЗМОЖНО_ реализовать без "манипулировании страницами пользовательского процесса".

Только если это сделано не в виде кривого хака.

>> И именно из-за того, что _хак_ кривой, требуется COW.

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

Естественно, иначе вообще бы не работал этот хак. И в реальной жизни он и не работает.

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

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

И как же оно узнает? Вы сами написали, что write() не блокируется, когда sndbuf больше размера передаваемого блока, теперь вопрос, когда же приложение узнает, что буфер освободился? Правильно, запишем второй буфер и дождемся, когда разблокируется эта запись. И что будет, если придет sack, если произошло congestion, если потребовалась повторная передача... Слишком много если для корректно работающего механизма. Анонимус выше указал, какие проблемы возникают, когда вообще нет гарантированной доставки и автоматической посылки подтверждений. А что произойдет, когда после посылки большого сообщения нужно послать маленькое и повторная запись не заблокируется? Ах, не надо посылать маленькое сообщение...

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

С 1999 года для единственной прошивки единственного драйвера... Да, я ошибся, это работает для гигабитного чипсета tigon.

>> Отсюда мы можем сделать вывод...

>Отсюда можно сделать вывод, что ты рассуждаешь чисто теоретически, при этом не зная деталей ни теории, ни практической реализации. Я, в отличии от "теоретиков с ЛОРа", это всё прощупал своими руками.

Надо полагать, что "прощупать" было не достаточно, потому как пока вы всего лишь переводите ман zero_copy. Покажите мне хоть один ваш тест производительности.

>baka-kun *** (*) (26.04.2006 19:29:13)

> Еще раз: для работы zero_copy_sockets COW _НЕ_ нужен,
> более того _вреден_. COW применяется только как
> защита буфера от некорректных/старых приложений.
При этом, однако, успешно маскируя "ошибки" и в
новых. Хотя тут трудно говорить об ошибках, раз
надёжного механизма проверки расшаренности страницы
всё равно нет.

> При этом последние продолжают работать без всякого
> переписывания и/или пересборки, не получая
> преимуществ, но и не ломаясь.
Вопрос в том, кто именно от него вообще может получить
преимущества. Ответ - никто. Или почти ни кто, что,
по сути, одно и то же. Т.к. вводить такой механизм,
ценой кучи хаков, только чтобы им воспользовалось
несколько человек в мире - ни это ли идиотизм в явном
виде? Вы всё же задайтесь вопросом - а почему именно
его отключили? Не по тому ли, что он оказался не
жизнеспособным?

> Нет. COW требуется только для того, чтобы не сломать
> совместимости и надежности.
... и при этом не получить вообще ни какого выигрыша
вообще ни в чём и ни где.
Так нафига было стараться? Уж лучше сделать сразу
новый, нормальный API, или не делать вообще ничего,
чем наворачивать хак на старый API, и потом с этого
всё равно ничего не поиметь.

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

> Нет. Ниже я предлагаю именно то, что написано в man
> -- повторно использовать буферы только после
> отправки минимум двух размеров буфера сокета. Такое
> поведение _гаранированно_ предотвращает COW.
... только во FreeBSD и только при работе с TCP.
И то, это достигается тем, что размер TCP-window
ставят равным размеру буффера сокета. А кто сказал,
что такой подход оптимален в плане производительности?
И спросите себя, сколько потребуется передавать
буфферов, если размер TCP-window будет больше размера
буффера сокета в N раз... Скажете, не бывает так?
Под фрёй - да, не бывает, но тем не менее, вот
цитата из какого-то дока:
http://www.ncsa.uiuc.edu/People/vwelch/net_perf/tcp_windows.html#how
---
Under Unicos setting the TCP window size is done a little differently. Instead of matching the window size to the socket buffer size, Unicos has a completely separate socket option for setting the window size.
The option sets the the number of bits the window is shifted left.
[и чуть далее пример]
setsockopt(sock, IPPROTO_TCP, TCP_WINSHIFT,
(char *) &window_shift, sizeof(window_shift));
---
Вполне возможно, что выставляя размер TCP-window
отдельно от размера буффера сокета, можно добиться
и большего увеличения производительности, чем даст
zero_copy_sockets.

> Я, в отличии от "теоретиков с ЛОРа", это всё
> прощупал своими руками.
А так же в отличии от Линуса, и от тех БСДшников,
что этот механизм отключили, ага.

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

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

Это он не подумав. Сначала ляпнул сгоряча одно, потом другое, пытаясь оправдаться. ;)

Скажи, в чем польза модификации буфера _одновременно_ с тем, как из него же идет передача?

> Надёжное ядро должно надёжно защищать одни процессы от ошибок в *других* процессах, но никак не в самих себе. :)

А что еще НЕ должно надежное ядро? НЕ должно защищать себя от процессов? НЕ должно защищать ядерные буферы от модификации приложениями, когда оно (ядро) с ними работает? Может еще и НЕ должно быть вытесняющим, а достаточно кооперативной многозадачности?

> Этот параграф мне было стыдно даже здесь цитировать на самом деле. :)

Если твоя задача -- выяснить истину, ты бы процитировал, и постарался понять написанное. Или попросил бы пояснить.

Ничего странного нет в том, что для оптимальной работы необходимо писать код ни абы как, а придерживаясь некоторых правил. И ничего необычного в том, что это FreeBSD only решение. Кому _действительно_ необходимо, тот воспользуется, а остальным даже и заморачиваться не надо. Это частное решение.

> Отлично! А если не TCP-based sockets?

Откровенно говоря, я ждал такого наивного вопроса. ;) Не надо объяснять, TCP -- это худший случай из всех возможных? Так вот, если некий способ гарантированно работает в случае TCP, неужели ты думаешь, что c fire-and-forget UDP будет хуже?

> Кое-кто хочет более портируемые приложения писать.

На здоровье, хотеть не вредно. Только ведь больше некуда портировать, нет под Linux zero-copy сокетов.

>> Понимают. И Линус прекрасно понимает, что ему не обойтись без расшаривания пользовательской страницы с ядром, если действительно необходимо _zero_-copy. То есть zero-copy _НЕВОЗМОЖНО_ реализовать без "манипулировании страницами пользовательского процесса".

> Только если это сделано не в виде кривого хака.

То есть ты уже не возражаешь, что "манипулирование страницами пользовательского процесса" необходимо, а единственно возражаешь против read-only на буфер? Прогресс!

Я правильно понимаю, что любой механизм, который внесет в ядро Линус не будет "кривым хаком", а все прочие реально работающие механизмы кривы "по определению Линуса"? Это, батенька, называется словом "фанатизм"... Или "религия"...

> И в реальной жизни он и не работает.

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

> Правильно, запишем второй буфер и дождемся, когда разблокируется эта запись. И что будет, если придет sack, если произошло congestion, если потребовалась повторная передача...

Алло? На той стороне кто-нибудь обдумывает прочитанное? Срочно разбираться в архитектуре IP стека BSD, и не пороть чушь!

>> COW применяется только как защита буфера от некорректных/старых приложений.

> При этом, однако, успешно маскируя "ошибки" и в новых. Хотя тут трудно говорить об ошибках

Естественно. Просто плохо написанное приложение не достигнет ожидаемой эффективности, то есть не будет работать как "zero-copy". Данные в любом случае будут доставлены неискаженными. Правильное приложение получит "быстрые" сокеты, остальные -- обычные.

> Вопрос в том, кто именно от него вообще может получить преимущества. Ответ - никто.

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

> Вы всё же задайтесь вопросом - а почему именно его отключили?

Ты наверное ошибся, и хотел сказать "не включили по умолчанию"? Уже говорилось: zero_copy_sockets в семантике стандартных сокетов не предназначены для общего пользования. Очень мало задач, которым это необходимо. Этот микроскоп предназначен для узкого круга, и заколачивать им гвозди не стоит, будешь похож на идиота.

> Так нафига было стараться? Уж лучше сделать сразу новый, нормальный API, или не делать вообще ничего

Зачем городить сущности, если с поставленной задачей справляется намного более простое и эффективное решение? К тому же, приложение сможет работать без переписывания на любой платформе, хоть zero-copy, хоть простой. BSD сокеты -- они и в Linux BSD сокеты.

> Понятия оно не имеет. И следовать всяким эвристическим методам,

Гхм... Они не эвристические, всё строго детерминировано и математически доказуемо.

> зависящим от реализации и от особенностей транспортного протокола, оно не обязано.

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

>> Такое поведение _гаранированно_ предотвращает COW.

> ... только во FreeBSD и только при работе с TCP.

Оба неверно: 1) приложение нигде не вызовет COW (написано с учетом специфики FreeBSD, а больше нигде таких сокетов нет), 2) если уж справились с TCP, то с прочими протоколами и подавно.

> И то, это достигается тем, что размер TCP-window ставят равным размеру буффера сокета.

Во FreeBSD (и не только) это так, а больше нигде нет таких zero-copy сокетов. Но даже если бы было иначе, надо было бы просто ориентироваться на размер TCP-окна.

> Вполне возможно, что выставляя размер TCP-window отдельно от размера буффера сокета, можно добиться и большего увеличения производительности, чем даст zero_copy_sockets.

Крайне маловероятно. Особенно на GRE или UDP ;)

> Это он не подумав. Сначала ляпнул сгоряча одно,
> потом другое, пытаясь оправдаться. ;)
А где там "другое"? Я видел только это. Можно ссылку?

> Скажи, в чем польза модификации буфера
> _одновременно_ с тем, как из него же идет передача?
Так я ж написал, что это мне и самому не понятно.
Но он так лихо это утверждал, и DaveM вроде тоже с
этим согласился... Хрен знает этих умников, может
и правда придумают какой-то странный случай, где
это даст какую-то пользу? По мне - так это только
глюки огребать, тут спорить не буду, но просто я
хочу сказать, что это можно классифицировать как
ошибку приложения, но не ядра.

> НЕ должно защищать себя от процессов?
Себя-то конечно должно, но пользовательские буффера -
разве это часть "себя"?

> НЕ должно защищать ядерные буферы от модификации
> приложениями
Ну это ж пользовательские буффера всё-таки. Сам их
передал - сам и испортил, ну ССЗБ, как тут говорят. :)
Но вреда системе-то при этом никакого. Ядро не
пострадает, другие процессы - тоже. В чём нарушение
защиты тут?

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

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

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

> а остальным даже и заморачиваться не надо. Это
> частное решение.
Ну а Линус вот не любит полумеры. И такие частные
решения считает злом. И решил он подождать и
разработать общее решение, а тех, кто внедряет
такие частные - назвал идиотами. Ну и в чём он не
прав? Каждое такое "решение" требует поддержки
разработчиков. Если "решением" никто не пользуется,
то никто его и не поддерживает, код загнивает,
потом его отключают. А смысл? У Линуса просто
другой подход к разработке. Такого вида частные
решения он считает идиотизмом. Разве он не прав?

> Не надо объяснять,
Тебе - не надо. Это должен объяснять всё тот же
мануал, а не ты. Если там написано, что это для
TCP, то всё остальное только на свой страх и риск.
И никакой здравый смысл тут не поможет. Либо
документировано, либо нет. Тем более когда
эвристических подходов касается...

> TCP -- это худший случай из всехвозможных?
Не знаю... SCTP берёшься прокомментировать?

> На здоровье, хотеть не вредно. Только ведь больше
> некуда портировать, нет под Linux zero-copy сокетов.
Вопрос - это хорошо, или плохо? Можно сказать:
плохо, т.к. нет замены. А можно сказать: отлично,
т.к. скоро будет vmsplice() & AIO, а пока и на обычных
сокетах посидеть не грех. Ну и где здесь правда? И
где она будет, когда всё необходимое и правда
появится?

>> Вполне возможно, что выставляя размер TCP-window
>> отдельно от размера буффера сокета, можно добиться
>> и большего увеличения производительности, чем даст
>> zero_copy_sockets.
> Крайне маловероятно.
Да, согласен. И вообще, разумеется, ставить размер
TCP-window больше буффера сокета - это я не подумав
сказанул... :)

В принципе, я думаю, можно подытожить. Спор пошёл
по двум направлениям: одно - приведёт ли предложение
Линуса к нестабильности системы, и второе - нужен ли
миру zero_copy_sockets, или его придумали идиоты (кстати,
одно другое не исключает - он может быть нужен в
отсутствии лучших решений, и тем не менее его
придумали идиоты :).
В то время как по первому пункту ещё можно
конструктивно поспорить, по второму - это уже дело
вкуса. Лично я считаю, что методика Линуса верна -
долой полумеры, эвристику и непортабельные хаки,
лучше день потерять, зато потом за час долететь.
Если кто-то считает иначе - его право.
Но последнее слово всё равно будет за нами, когда
доделают vmsplice() & AIO.

>>> Понимают. И Линус прекрасно понимает, что ему не обойтись без расшаривания пользовательской страницы с ядром, если действительно необходимо _zero_-copy. То есть zero-copy _НЕВОЗМОЖНО_ реализовать без "манипулировании страницами пользовательского процесса".

>> Только если это сделано не в виде кривого хака.

>То есть ты уже не возражаешь, что "манипулирование страницами пользовательского процесса" необходимо, а единственно возражаешь против read-only на буфер? Прогресс!

Во freebsd только с помощью (кривого) манипулирования. В Linux такое никогда не будет включено в ядро.

Я возражаю против такого подхода _вообще_, т.к. мои собственные тесты производительсноти для Linux (подсовывание skb->data страницы в пространство пользователся) хоть и показали очень большое преимущество в скорости, но я, тем не менее, понимаю, что этот подход порочен, и где кроются огромные пододные камни, которые полностью уничтожат любой выигрыш. Разработчики freebsd тоже понимают, что этот кривой хак не дает роста производительности на настоящих задачах, поэтому и отключили его по умолчанию.

>Я правильно понимаю, что любой механизм, который внесет в ядро Линус не будет "кривым хаком", а все прочие реально работающие механизмы кривы "по определению Линуса"? Это, батенька, называется словом "фанатизм"... Или "религия"...

Дело в том, что я _знаю_ о том, как работает такой хак, т.к. сам делал его для Linux, публиковал и выслушивал комментарии несколько лет назад (желающие могут поискать в архивах, rtc - аббревиатура ФИО), и я знаю где там грабли. Это _очень_ кривой механизм, а не "прочие реально работающие", хотя спору нет, он работает, и иногда очень хорошо.

То, что примет Линус, пройдет проверку десятка опытнейших ядерных хакеров и одних из лучших компьютерных разработчиков в мире, поэтому то, что включено, по определению не будет являться хаком (на данный момент).

>> И в реальной жизни он и не работает.

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

Да, смотри абзац выше. Для Linux, не для freebsd. Идея абсолютно та же (реализована была только принимающая часть, т.к. проще и в принципе нет COW, т.к. все страницы были только на чтение).

>> Правильно, запишем второй буфер и дождемся, когда разблокируется эта запись. И что будет, если придет sack, если произошло congestion, если потребовалась повторная передача...

>Алло? На той стороне кто-нибудь обдумывает прочитанное? Срочно разбираться в архитектуре IP стека BSD, и не пороть чушь!

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

Предлагаю завершить дискуссию.

Мое резюме по этому вопросу следующее: во freebsd сделан кривой хак, который работает только с одним драйвером и одной прошивкой сетевой карты (приемная часть с разделением заголовков), выключен по умолчанию, и, как показали тесты, ведет к росту производительности даже не в еденичных случаях, а исключительно "для сферического коня в вакууме". Работа с этим механизмом неудобна, требует серьезных изменений в архитектуре приложения, знаний о работе ядра, нетривиальных настроек параметров стека TCP/IP, которые могут привести к неработоспособности и резкому снижению производительности для остальных приложений и т.п.

Тем не менее, такой механизм существует и наверное кем-то применяется во freebsd.

Для справки: в Linux в виде сторонних патчей также существует receiving zero-copy (в файл, требует аппаратуры, поддерживающей разделене заголовков или использующей mmio read), sending zero-copy для пользовательский страниц.

>baka-kun *** (*) (27.04.2006 1:54:25)

>> Правильно, запишем второй буфер и дождемся, когда разблокируется эта запись. И что будет, если придет sack, если произошло congestion, если потребовалась повторная передача...

>Алло? На той стороне кто-нибудь обдумывает прочитанное? Срочно разбираться в архитектуре IP стека BSD, и не пороть чушь!

Just a question: а что, если было записано два буфера, в сумме которые меньше sndbuf, затем третий, который заснул. Когда третий вызов был завершен, это означает, что _все_ данные из предыдущих буферов были отправлены в сеть, или только первый?

Но я конечно понимаю, что zero-copy sockets не предназначены для такого поведения, но тем не менее такая ситуация возможна, и с большой вероятностью приведет к COW, что приведет к падению производительности, нескомпенсированному мнимым ростом zero-copy.

>baka-kun *** (*) (27.04.2006 1:54:25)

> желающие могут поискать в архивах
А как на счёт "ссылку в студию"? И хотя бы в архивах
чего? ЛОРа? :)

>> желающие могут поискать в архивах

>А как на счёт "ссылку в студию"? И хотя бы в архивах чего? ЛОРа? :)

Нет, ЛОР я только недавно начал читать - коллега ссылку прислал вместо anetkdot.ru.

> Но последнее слово всё равно будет за нами, когда
> доделают vmsplice()
А, ОК, vmsplice() уже там. Хм, оперативно... :)

>> Но последнее слово всё равно будет за нами, когда > доделают vmsplice()

>А, ОК, vmsplice() уже там. Хм, оперативно... :)

Для сокетов наверное не скоро сделают - сейчас в моде Van Jacobson's network channels :)

>> А, ОК, vmsplice() уже там. Хм, оперативно... :)
> Для сокетов наверное не скоро сделают
А нафига его далеть именно для сокетов? Сделал
vmsplice() в пайп, а потом сделал splice() этого пайпа
уже в сокет. Или я что-то не так понял?

>>> А, ОК, vmsplice() уже там. Хм, оперативно... :) > Для сокетов наверное не скоро сделают

>А нафига его далеть именно для сокетов? Сделал vmsplice() в пайп, а потом сделал splice() этого пайпа уже в сокет. Или я что-то не так понял?

Можно было бы сразу vmsplice() из userspace в сокет (соответствующие ->in() и ->out() методы реализовать). Можно и через splice(), но пока ни то, ни другое не сделано. Сетевые разработчики обдумывают новые идеи Ван Якобсона, до идей Линуса Торвальдса и Дженса Аксбо им пока нет вермени. Ван, как-никак, намного более интересные сетевые идеи двигал: и congestion control, и TCP prequeue, и header prediction.

> Можно было бы сразу vmsplice() из userspace в сокет
> (соответствующие ->in() и ->out() методы реализовать).
> Можно и через splice(), но пока ни то, ни другое не
> сделано.
Не понимаю... Ну хорошо, а vmsplice() в пайп, и потом
sendfile() в сокет - это будет работать?

>> Можно было бы сразу vmsplice() из userspace в сокет > (соответствующие ->in() и ->out() методы реализовать). > Можно и через splice(), но пока ни то, ни другое не > сделано.

>Не понимаю... Ну хорошо, а vmsplice() в пайп, и потом sendfile() в сокет - это будет работать?

Теоретически да, так должно работать.

Кстати, sendfile() рано или поздно переделают в splice(), тогда можно будет сразу vmsplice()->splice()->network и vmsplice()->network.

>> Не понимаю... Ну хорошо, а vmsplice() в пайп, и потом
>> sendfile() в сокет - это будет работать?
> Теоретически да, так должно работать.
Ну и с чего тогда вдруг splice() в сокет не будет
работать? Чем sendfile() настолько проще реализовать,
и в чём принципиальная проблема со splice()?

>>> Не понимаю... Ну хорошо, а vmsplice() в пайп, и потом >> sendfile() в сокет - это будет работать?

>> Теоретически да, так должно работать.

>Ну и с чего тогда вдруг splice() в сокет не будет работать? Чем sendfile() настолько проще реализовать, и в чём принципиальная проблема со splice()?

О, появился generic_splice_sendpage() как ->splice_write() callback. Когда я смотрел последний раз этого еще не было.

Так что splice() в сокет из файла (из pipe в нотации автора) уже работает, так что vmsplice()->splice()->network тоже.

> Так что splice() в сокет из файла (из pipe в нотации
> автора) уже работает, так что vmsplice()->splice()->network
> тоже.
Думаю, и vmsplice() сразу в сокет если и не работает, то
в скором времени тоже работать будет.
Ну, собсно, вот и всё. Куда все БСДшники пропали, ау? :)
У кого-небудь ещё будут возражения против действий
Линуса, характеристик, озвученных им, и тд? :)