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

>ну и бил бы Линус морды коллегам, занимающимся вместе с ним розработкой того же ядра,

Дык эта... далеко :)

> > У них разное количество аргументов. Как их можно сравнивать?
>
> и еще они по разному называются и что?
> это две функции выполяняющие "open",
> настоящяий sys_open только их вызывает, а то сколько аргументов
> они принимают, это дизайн ОС, и тоже может видеть насколько он хорош.

Да, это две функции выполняющие "open", но с разным количеством входных данных. Могу с уверенностью предположить, что реализация аналогичной функции в DOS ещё проще. Ну и что?

P.S. посылая сюда код включите "Preformatted text" внизу слева.

>Я имел ввиду, если бы он тему "идиотов русских" после прочтения лора описал бы в списке рассылки.

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

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

перечитай сам, я на этот бред уже ответил

Гик, последнее слово хочется за собой оставить?

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

> Я имел ввиду, если бы он тему "идиотов русских" после прочтения лора описал бы в списке рассылки.

"Вот если бы взять груди Евдокии Тихоновны
да приставить к ушам Авдотьи Ефимовны,
а сверху прицепить ногу Зинаиды Григорьевны,
то ведь это же черт знает какая пакость получится."

(цэ) Роман Воронежский

shimon, ну может аналогия немного за уши притянута. Но тем не менее, зная (а Линус не может не знать) что слова получат определенный общественный резонанс, повел он себя странно.

Целенаправленно (это было бы понятно, хотя причина не ясна) или действительно по дурости наехал на группу посторонних людей. Наехал публично.

В гугле поищи, резонанс определенный таки есть.

а вот комментарии по этому поводу из freebsd-questions,
сдержанно,сухо и по делу. Те кому интересен предмет спора, я думаю
в состоянии понять текст без перевода

From: Peter <petermatulis@yahoo.ca>
To: freebsd-questions <freebsd-questions@freebsd.org>
Subject: anyone understand torvald's critique of freebsd?

Does anyone here understand Linus Torvald's recent comments on FreeBSD?
http://bsdnews.com/view_story.php3?story_id=5735
-------------------------------------------------
From: Kris Kennaway <kris@obsecurity.org>
To: Peter <petermatulis@yahoo.ca>
Subject: Re: anyone understand torvald's critique of freebsd?

On Fri, Apr 21, 2006 at 08:56:29PM -0400, Peter wrote:
> Does anyone here understand Linus Torvald's recent comments on FreeBSD?
>
> http://bsdnews.com/view_story.php3?story_id=5735

He's railing against an option (options ZERO_COPY_SOCKETS) that is
not enabled by default in FreeBSD anyway for basically the same reasons he
says.

kris

---------------------------------------------------
From: Chuck Swiger <cswiger@mac.com>
To: Peter <petermatulis@yahoo.ca>
Subject: Re: anyone understand torvald's critique of freebsd?

Peter wrote:
>Does anyone here understand Linus Torvald's recent comments on FreeBSD?
>
>http://bsdnews.com/view_story.php3?story_id=5735

Sure. There are different ways of moving data between the kernel and
userland; the classic mechanism involves copying data from a wired-down page
in kernel space allocated to network memory buffers to a userland page via
copyin() and copyout() (or equivalents).

Mach (and apparently the ZERO_COPY_SOCKETS option to FreeBSD) manipulate the
VM page table mappings to make that page visible in the process address
space rather than copying the sequence of bytes manually via a
message-passing paradigm.
The former approach tends to be more efficient for small amounts of data,
especially for things smaller than one page of memory (ie, all non-jumbo
network traffic); the latter approach tends to better for things which are
bigger in size.

The Mach VM has more overhead to its operations because the VMOs are more
complicated to work and a given workload will result in comparatively larger
VMO datastructures than the less-complicated approaches to doing VM. On the
other hand, Mach was the first or among the earliest platforms to support
shared libraries, dynamic loading of objects into user processes (dlopen vs.
dso) and into the kernel, and has somewhat better scaling in the face of
gigabytes of RAM and VM usage than most Unix flavors do (outside of Solaris,
although FreeBSD is pretty decent nowadays too).

Mach handles mapping shared libraries into VM via a technique called
prebinding that can minimize the work and memory overhead required for
runtime symbol relocation, which tends to big win if you are running a lot
of, say, Java or Perl processes that make extensive use of runtime
class-loading, yet is flexible enough to deal with collisions if needed
(whereas the older fixed-VM shared libraries were subject to evil nasty
conflicts if your data segment grew too big and overlapped a library's
chosen address space, or if two libraries wanted to be mapped into the same
spot).

--
-Chuck

> Разумные люди увидели в его письме аргументы и логику

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

The thing is, the cost of marking things COW is not just the cost of the initial page table invalidate: it's also the cost of the fault eventually when you _do_ write to the page ... In real life, COW-faulting overhead is expensive.

Он абсолютно прав, COW на i386 -- достаточно дорогая операция. А теперь давай прочитаем man zero_copy:

The user should be careful not to overwrite buffers that have been written to the socket before the data has been freed by the kernel, and the copy-on-write mapping cleared. If a buffer is overwritten before it has been given up by the kernel, the data will be copied, and no savings in CPU utilization and memory bandwidth utilization will be realized.

Ну как? Линус говорит: "FreeBSD идиоты -- если перезаписывать буфер, то будет COW, а это дорого".

А FreeBSD уже несколько лет говорит: "ребята, не перезаписывайте буфер раньше времени, а то будет copy-on-write, а это дорого". И кто после этого идиот? ;)

PS. Хорошо хоть признает: "The COW approach does generate some really nice benchmark numbers, because ... you never actually write to the user page in the first place". Если еще до него дойдет, что корректно написанное приложение тоже не пишет в буфер, пока тот не освободится (соответственно показевает цифры не хуже)...

По-хорошему, Линусу сейчас бы уточинь свою позицию не помешает.

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

Кто читает этот список рассылки - ничего подобного не было?

P.S. А вообще-то не первый раз он такое себе позволяет. Вон помнится как-то на розработчиков GNOME наехал.

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

> пользы...

Золотые слова. TruЪ!

> Если Линус не извенится перед разработчиками БЗДи-я буду его считать

> ламером и пересяду на другую ОС

Как же легко тебя сподвигнуть на всякого рода резкие телодвижения! Всего одна фраза, и дело в шляпе. Ты просто подарок для тех, кто хочет тобой манипулировать :)

> P.S. А вообще-то не первый раз он такое себе позволяет. Вон помнится как-то на розработчиков GNOME наехал.

Линус Торвальдс - наш кумир,
Идиотам глаз раскрыл.

Дело в том, что Линус не может ошибаться по определению. Если он говорит идиоты, то быстрей всего так и есть. Да это звучит грубо. Но как можно по другому говорить с дураками?

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

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

За такое мнение срок дают в цивилизованых странах. Хотя Линус-обариген.

Линус прав. Я сам над этим очень часто думал, но был не уверен в умственных способностях бздишников. Спасибо Линусу-он развеял мои сомнения.

казёл

From: Matthew Dillon  Article: VM Design
Перед тем, как перейти непосредственно к существующей архитектуре, потратим немного времени на рассмотрение вопроса о необходимости поддержки и модернизации любого длительно живущего кода. В мире программирования алгоритмы становятся более важными, чем код, и именно из-за академических корней BSD изначально большое внимание уделялось проработке алгоритмов. Внимание, уделенное архитектуре, в общем отражается на ясности и гибкости кода, который может быть достаточно легко изменен, расширен или с течением времени заменен. Хотя некоторые считают BSD ''старой'' операционной системой, те их нас, кто работает над ней, видят ее скорее системой со ''зрелым'' кодом с различными компонентами, которые были заменены, расширены или изменены современным кодом. Он развивается, и FreeBSD остается передовой системой, вне зависимости от того, насколько старой может быть часть кода. Это важное отличие, которое, к сожалению, не всеми понимается. Самой большой ошибкой, которую может допустить программист, является игнорирование истории, и это именно та ошибка, которую сделали многие другие современные операционные системы. Самым ярки примером здесь является Windows NT®, и последствия ужасны. Linux также в некоторой степени совершил эту ошибку--достаточно, чтобы мы, люди BSD, по крайней мере по разу отпустили по этому поводу шутку. Проблема Linux заключается просто в отсутствии опыта и истории для сравнения идей, проблема, которая легко и быстро решается сообществом Linux точно так же, как она решается в сообществе BSD--постоянной работой над кодом. Разработчики Windows NT, с другой стороны, постоянно совершают те же самые ошибки, что были решены в UNIX® десятки лет назад, а затем тратят годы на их устранение. Снова и снова. Есть несколько случаев ''проработка архитектуры отсутствует'' и ''мы всегда правы, потому что так говорит наш отдел продаж''. Я плохо переношу тех, кого не учит история.

Большинство очевидной сложности архитектуры FreeBSD, особенно в подсистеме VM/Swap, является прямым следствием того, что она решает серьезные проблемы с производительностью, которые проявляются при различных условиях. Эти проблемы вызваны не плохой проработкой алгоритмов, а возникают из окружающих факторов. В любом прямом сравнении между платформами эти проблемы проявляются, когда системные ресурсы начинают истощаться. Так как я описываю подсистему VM/Swap во FreeBSD, то читатель должен всегда иметь в виду два обстоятельства. Во-первых, самым важным аспектом при проектировании производительности является то, что называется ``оптимизацией критического маршрута''. Часто случается, что оптимизация производительности дает прирост объема кода ради того, чтобы критический маршрут работал быстрее. Во-вторых, четкость общей архитектуры оказывается лучше сильно оптимизированной архитектуры с течением времени. Когда как обобщенная архитектура может быть медленнее, чем оптимизированная архитектура, при первой реализации, при обобщенной архитектуре легче подстраиваться под изменяющиеся условия и чрезмерно оптимизированная архитектура оказывается непригодной. Любой код, который должен выжить и поддаваться поддержке годы, должен поэтому быть тщательно продуман с самого начала, даже если это стоит потери производительности. Двадцать лет назад были те, кто отстаивал преимущество программирования на языке ассемблера перед программированием на языке высокого уровня, потому что первый генерировал в десять раз более быстрый код. В наши дни ошибочность этого аргумента очевидна--можно провести параллели с построением алгоритмов и обобщением кода.
-greeen

>> Сокет - это не то место, куда можно ставить такие кривые костыли.

>Says who? Сокеты - это именно то место, где дополнительной функциональности сокетов же и надлежит быть.

Так вы уж определитесь, что пишете - драйвер для узкоспециализированной железки, или все же общий механизм zero-copy sockets? Если второе, то это некорректно из-за уже неоднократно описанных проблем.

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

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

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

>> Не нужно путать теплое с мягким, область применения /dev/mem не > сравнима с _некорректным_ механизмом работы zero-copy sockets.елу > проекта.

>Для того, для чего они были разработаны, zero-copy sockets работали и работают великолепно. Мне надоело повторять это из раза в раз - не разрабатывался этот механизм для всеобщего использования и никогда так не позиционировался никем вне воспалённого воображения Торвальдса.

Так, по порядку, сокеты - это механизм общего пользования? Да, насколько я знаю. Релизацию zero-copy в них присутствует? Да. Т.о. мы имеем обощенную реализацию zero-copy sockets, которая работает для любой сетевой карты, для любого протокола и т.п.

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

Об этом вам и повторяют - такая реализация механизма zero-copy для сокетов некорректна, чтобы не говорили поклонники ОС, в которой это было разработано.

>> Я бы "посадил" память в pci бар и отобразил бы ее через mmap. > Оттуда, используя read/write для памяти и обычного сокета, посылал > бы данные в сеть. > Понимаю, что для хитрого железа это могло бы быть очень накладно, и > тогда можно было бы придумывать механизмы передачи данных от одного > физического адреса в другой и т.п. Но это бы точно не жило в коде > сетевого стека.

>Мелкая придирка: в бар бы ты "посадил" _адрес_, а никак не саму память :) Вдумчиво перечитай описание кофигурации и расплачься над "используя read/write для памяти и обычного сокета". Заодно расскажи как бы ты принимал/посылал данные по TCP/IP вне TCP/IP стека. Написал бы свой, я так понимаю. Боюсь авторам zero-copy sockets было не до великих свершений.

Вы о чем? Я посылаю данные из пользовательского контекста, используя механизм send()/write(), стек уже давно написан и спрятан внутри. Такой подход портабелен и разве что не позволет избежать двух копирований на границе kernelspace/userspace, это может быть критично для производительности, и для какого-то отдельно драйвера может быть реализовано в виде подмешивания страниц в VM, но как реализация механизма zero-copy sockets, применимого для остальных задач, это некорректно, т.к. ... Наша песня хороша, начинай сначала...

>> Идея zero copy transfer очень верна, но сами сокеты для нее не > предназначены. Для корректной работы сокетов с механизмом zero-copy > нужно изобретать костыли вроде aio completion и т.п. А уж вариант с > перемешиванием страниц в VM - это полный превед. Именно это нужно > прочесть в словах Торвальдса.

>Прочbтали. Кивнули, потому как ничего нового "competent geniuses" не сказали. Непонятно только, чего гений так раскорячился со своими "идиотами".

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

>kan * (*) (23.04.2006 4:55:02)

>> Вот-вот, костыли в виде aio completion - это во-первых.

>У тебя есть какие-то другие варианты? Какой еще способ предотвратить запись в буфер "на лету" можно предложить, кроме установки на него read-only (что выливается в COW для кривого приложения, но зато спасает от искажения данных)? Тебе _в_любом_ случае потребуется или синхронизация, или защита буфера от записи.

Конечно есть. Во-первых, не нужно использовать сокеты и любые другие _синхронные_ механизмы передачи данных для асинхронного контекста. Сокет - это прошлый век, хотя конечно спору нет, очень эффективный механизм. Во-вторых, механизм передчи данных должен отличаться от "возьми оттуда, положи туда", это должно быть "положи это туда", как sendfile(), как pipe. Стоит заметить, что здесь нет локов и ожиданий.

>> Торвальдс говорит не о том, что zero-copy sockets есть идиотизм

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

>Ты видишь, в чем разница? Во FreeBSD zero_copy _уже_ работает, и корректно написанное приложение может получить заметное преимущество, а в худшем случае ошибка пользователя приведет к COW, что отразится только на скорости (потеряется сотня таков процессора), причем незначительно (по сути, как если бы zero_copy не было совсем), зато данные останутся в целости и сохранности.

Любое приложение приведет к COW, т.к. congestion, временное нарушение роутинга, переполненный буфер сокета и все, приложение либо засыпает, либо COW, первое криво, второе снижает производительность.

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

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

>Все его возражения сводятся к "COW на i386 -- это медленно". Всё. Это возражения PC-хакера, а юникс разработчика. Даже просто использование двух буферов поочередно сводит вероятность COW во FreeBSD к минимуму, что, естественно, Линус тоже не заметил.

COW на любой архитектуре риведет к очень большой потере производительности. Везде, где происходит double page fault, потенциально ошибка в дизайне.

>baka-kun *** (*) (23.04.2006 2:20:18)

>А FreeBSD уже несколько лет говорит: "ребята, не перезаписывайте буфер раньше времени, а то будет copy-on-write, а это дорого". И кто после этого идиот? ;)

>PS. Хорошо хоть признает: "The COW approach does generate some really nice benchmark numbers, because ... you never actually write to the user page in the first place". Если еще до него дойдет, что корректно написанное приложение тоже не пишет в буфер, пока тот не освободится (соответственно показевает цифры не хуже)...

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

Так вопрос, зачем такие кривые хаки вообще?

>baka-kun *** (*) (23.04.2006 11:27:50)

>Во-вторых, механизм передчи данных должен отличаться от "возьми оттуда, положи туда", это должно быть "положи это туда", как sendfile(), как pipe. Стоит заметить, что здесь нет локов и ожиданий.

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

Ха! Молодец Линус. Давить хадов! Ждем ебидофф!

> rtc (*) (23.04.2006 13:44:04) Повторим историю с микроскопом? Когда вы увидите человека, вбивающего гвоздь таким прибором, вы ведь не подумаете, что этот человек в здравом уме и трезвой памяти? Торвальдс это и озвучил.

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

Не, анонимус, ты -- идиот. Раз на слово "идиот" отгавкиваешься.

-- Линус, а давай кривой костыль воткнем. -- Нет! -- Но во FreeBSD его воткнули... -- Нет! -- Но во FreeBSD давно воткнули! -- Нет, не будет никакого кривого костыля! -- Но во FreeBSD говорят, производительность растет! -- Значит, они идиоты, а у нас кривого костыля не будет! И точка!

...Ибо некоторым ну очень трудно объяснить. А обижаться будут только идиоты.

Разгул идиотии. Ждём когда Линус извиниться, сославшись на то, что он стар, у него дочка... да и вообще с женой поругался.

Линус не ведает что творит. Как этого старичка еще допускают к координированию проекта. С таким набыченым характером он отпугнет всех желающих помочь.

> С таким набыченым характером он отпугнет всех желающих помочь.

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

Кривые костыли обычно в линукс втыкают, если вам интересно сравнить составьте статистику.

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

Сколько этому проституту заплатили?

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

А какие с этим проблемы? Ну будешь ты проверять какой-нибудь флажок или сообщение получишь. Вот при программировании COM-портов есть же такой флажок "Данные отправлены", который рекомендуется проверять перед оправкой следующей порции данных. Ну так что-то никто не плакал, что это надо было делать. Какие проблемы вообще? Или это лучше, если ты получишь здоровый лаг в случае повторной записи? К тому же зависимость от поведения архитектуры -- это вообще не гуд. Наиболее общий подход -- это любые возможные способы синхронизации, отвязанные от архитектуры вообще. Если юзер постоянно пишет раньше времени, то это будет означать, что он отклоняется от методики и делает неправильно. Один раз исправит, и все дела. К тому же, для подавляющего большинства задач достаточно обычного поведения через user space. Подход через zero copy нужен в случае, когда нужна максимальная скорость. Ну тогда уж будьте добры придерживаться несложной методики, раз хотите быстро.

З.Ы. Лично мне выпад Линуса не очень понравился, так как как-то неадекватно он наехал. Но это все уже из области его личных качеств. Пусть его жена и дети этим озаботятся, а не анонимусы с ЛОРа. Или разработчики устроят акцию сбора подписей аналогичную "миллион против Киркорова". :)

>Либо иди к окулисту на лечение. либо кончай врать.

Ты в обсуждение HIG'а и слов Linus'а зайди, а потом поговорим на тему оккулистов.

>Мой сосед построил себе дом - и его мнение при строительстве моего дома учитываться не будет - он же не строил МОЙ дом

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

P.S. Я не имел в виду, что FreeBSD - это деревянный домик, а Linux - каменный особняк. Это просто сравнения.

>Если Линус не извенится перед разработчиками БЗДи-я буду его считать ламером и пересяду на другую ОС. А за одно уведу всех своих друзей с этой поделки Линуса Торвадаса.

Я-то надеялся, что вы все просто апстену. ;)

Еще можете совершить акт самосожжения перед посольством США.

Xaxaxaxa, чего всполошились ? 8) Манипулирование таблицами не такая уж редкость, делается с благими намерениями - оборачивается, как правило, гемором. То что Линус против - вобщемто понятно. Форма протеста, правда, хамством попахивает 8) Ну да чего там удивляться, после того, как Линус пытался в сенаторы выползти - то удивительно, что так мягко 8) Шел бы он что-ли в эти сенаторы - больше толку линуксу бы было... И Мортона еще бы с собой прихватил ;)

Нам должно быть стыдно за Линуса. Нужно сделать так, что бы не только нам было стыдно, но и ему.

Гы-гы. Если бы Линус не ругнулся, то вряд ли бы кто тут озаботился такими проблемами, как zero copy. :) В ядреных мэйл-листах таких вещей масса обсуждается. А Мортон еще жаловался, что кернел-публика стала более пассивна. Вот и способ -- ругаться с Линусом почаще на всех. Публика сама потянется. Можно русский мат выучить даже, чтобы было инетреснее. :)

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

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

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

Я просто обобщил подход FreeBSD и vmsplice() под названием "zero copy" (Линус все это тоже так обзывает). Я имел в виду под zero copy не конкретно подход FreeBSD, сделанный для частной задачи, а как противопоставление подходу через user space. И я не обсуждал частные ограничения каких-то решений в данный момент.

> Во-первых, не нужно использовать сокеты ... Сокет - это прошлый век

Сейчас я снова это скажу: "сокеты _уже_ _есть_. И они работают" ;)

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

> Любое приложение приведет к COW, т.к. congestion, временное нарушение роутинга, переполненный буфер сокета и все, приложение либо засыпает, либо COW

Противоречие видишь? Если сеть работает много медленнее, чем мы успеваем подготовить данные, то уже плевать, copy-on-write там, или блокировка, или еще что. Нам _абсолютно_ наплевать. То есть _совсем_.

> Не находите скрытое противоречие?

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

> Если приложение спит, то оно не обрабатывает данные,

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

> произодительность будет низкая,

С чего бы это? Будет _максимально_возможная_.

> если обрабытывает данные, получаем COW, еще хуже.

Это у Линуса будет COW, или в плохо спроектированном приложении. Кто тебя заставляет раньше времени трогать занятый ядром буфер?

Фишка в том, что если мы работаем _медленнее_ сети, то данные будут убегать раньше. Если быстрее, то сделать так, чтобы к посылке следующего буфера ядро было по уши забито предыдущими данными, и вынуждено было нас заблокировать. То есть проследить, чтобы в ядре всегда данных было больше SO_SNDBUF.

>Фишка в том, что если мы работаем _медленнее_ сети, то данные будут убегать раньше. Если быстрее, то сделать так, чтобы к посылке следующего буфера ядро было по уши забито предыдущими данными, и вынуждено было нас заблокировать. То есть проследить, чтобы в ядре всегда данных было больше SO_SNDBUF.

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

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

Да никаких проблем, собственно. Это, конечно, уже не socket будет в чистом виде, но не беда, не так сложно все приложения переписать.

Проблема в другом: как ты будешь защищать от изменений буфер, с которым в данный момент работает ядро, расшарен ведь? FreeBSD в случае zero_copy просто помечает сегмент read-only, а при исключении (запись приложением в буфер) делает COW, дальше ядро продолжает работать с оригинальными данными, приложение получает копию, этой ситуации рекомендуется избегать. Как -- описано. Но даже и так _работать_будет_, хоть и медленнее. А вот если ты не дождешься своего сообщения, или с флажком чего случиться, то будет жопа.

Ты можешь ответить "никак не буду защищать, пусть приложение само разбирается". Хорошо, может тогда подумать, в каких еще случаях ядро может наплевать, и позволить приложению менять ядерные (по факту) буферы? Может нам тогда вообще не заморачиваться с копированием (или другой передачей) данных в контекст ядра, пусть доступ всегда и везде будет in-flight? Представляешь, как скорость работы возрастет? А если еще кооперативную многозадачность ввести, да на одном кольце всё крутить... Сказка будет, а не система...

> Или это лучше, если ты получишь здоровый лаг в случае повторной записи?

А ты его мерял? Я -- да. Незначительно медленней, чем если использовать простые сокеты без zero_copy.

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

Именно это и написано в man zero_copy: "нужна максимальная скорость, придерживайтесь несложной методики".

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

> А другая фишка в том, что завтра у нас процессор в 10 раз быстрее стал.

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

>и так кстате везде,

if else goro bad рулит. qbasic кстати тоже. профисеанально.

> Совершенно верно. Если сосед по своим личным половым мотивам присособил для отопления "буржуйку" на торфе (В лесу - ВЫГОДНО!) и коптит ею в своем удовольствие, а тебе настойчиво предлагают сделать тоже самое уже здесь, в ТВОЕМ доме.

Я что-то не понял -- это что, разработчики FreeBSD Линусу что-то предлагают? Или всё же красноглазые, удидив что-то в FreeBSD, пытаются это перетащить в линукс?

> AVL2 *** (*) (23.04.2006 6:40:04)

Sic!

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

Так разработчики FreeBSD разве Линусу что-то предлагали? Нет, так почему их называют идиотами, если они сделали тонкое решение для специальной проблемы, и полностью описали, что решение ни в коей мере не является общим?

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

Полная чушь! Во-первых, в США такой плакат прировняют к неприличным, и на улице не повесят. Был, знаю. Это вам не Европа!

> geek ## (*) (23.04.2006 10:08:55)

> P.S. А вообще-то не первый раз он такое себе позволяет. Вон помнится как-то на розработчиков GNOME наехал.

А на GNOME мы и в OpenBSD наезжаем! ;) Вот, недавно, был прецедент с GNumeric.