Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Все, все, все. Больше у меня ни сил ни возможностей нет. При столь фантастическом непонимании основ современных ОС и файловых систем я больше никаких аргументов не имею и не могу иметь. Бессмысленно продолжать, так как надо читать целый курс, а на это у меня ни сил ни времени ни желания нет.
Как работают современные ОС я в курсе. Ни один толмуд на эту тему прочитал.
А еще я много думал на счет того как должны быть устроены правильные ОС.
А ты давай попробуй объяснить в чем принципиальная разница между файловой системой и SQL сервером?
Ибо и то и другое персистентные хранилище информации.
Единственная разница это способ структурирования этой самой информации.

Здравствуйте, WolfHound, Вы писали:

WH>А ты давай попробуй объяснить в чем принципиальная разница между файловой системой и SQL сервером?
Файловая система тесно интегрирована с ядерным менеджером кэша и системой виртуальной памяти. Т.е. фичи типа sendfile могут работать очень быстро.

И сделать такое обобщённо может и не получится — абстракции текут (к примеру, требуется особое выравнивание для того, чтобы работало DMA и т.п.).

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Все, все, все. Больше у меня ни сил ни возможностей нет. При столь фантастическом непонимании основ современных ОС и файловых систем я больше никаких аргументов не имею и не могу иметь. Бессмысленно продолжать, так как надо читать целый курс, а на это у меня ни сил ни времени ни желания нет.
WH>Как работают современные ОС я в курсе. Ни один толмуд на эту тему прочитал.

Не знаю, что ты прочитал, но не в коня корм.

WH>А еще я много думал на счет того как должны быть устроены правильные ОС.

А то до тебя никто не думал.


WH>А ты давай попробуй объяснить в чем принципиальная разница между файловой системой и SQL сервером?

Объяснять я ничего не буду. Этот флейм тут уже не раз устраивался, да и Cyberax ответил, я мог бы добавить, но и этого не буду. Отмечу лишь маленькое такое передергивание. Если речь идет о файловых системах на основе SQL (вроде то ли закрытого, то ли нет проекта MS насчет SQL-файловой системы) — это может быть темой для реального проекта и темой для обсуждения. А вот представление о MySQL как о дисковой подсистеме есть, извини, чушь несусветная. И представление твое об отличии драйвере от программ есть то же самое. Элементарное непонимание основ реальной системы, с которой ты работаешь. И нежелание понять.

WH>Ибо и то и другое персистентные хранилище информации.
WH>Единственная разница это способ структурирования этой самой информации.

Фантастическая способность с апломбом говорить , не разбираясь совершенно в сути вопроса. Персистентное хранилище — и все. Вся история и вся практика развития ОС и ФС за 50 лет коту под хвост.

Вот до чего абстракции людей доводят, когда они не подкрепляются знанием конкретики.

Здравствуйте, Cyberax, Вы писали:

C>Файловая система тесно интегрирована с ядерным менеджером кэша и системой виртуальной памяти. Т.е. фичи типа sendfile могут работать очень быстро.
1)Что мешает тоже самое сделать с SQL сервером?
2)В правильных ОС фичи типа sendfile не нужны ибо они будут получатся автоматически.

C>И сделать такое обобщённо может и не получится — абстракции текут (к примеру, требуется особое выравнивание для того, чтобы работало DMA и т.п.).
Никуда оно не течет.
ОСь аля сингулярити. Следи за руками:
1)Приложение SQL среверу: Дай мне вон тот блоб на пару гигов.
2)SQL сревер файловой системе: Заверни кусок того файла от сих до сих в поток.
3)Файловая система драйверу винта: Вот тебе поток сложи в него такие то блоки.
4)Файловая система SQL среверу: держи поток.
5)SQL сревер приложению: держи поток.
6)Приложение сетевому соединению: Отправь поток.

Все! Вот тебе sendfile. И без единой протечки.
Драйвер винта будет запихивать в поток страницы, а драйвер сетевухи будет доставать из потока массивы которые выровнены драйвером винта.
Накладные расходы только на обслуживание потока. И проверку того что очередной кусок действительно выровнен. Иначе через DMA отправляем подмассив который выровнен, а начало и/или конец как придется. От современных ОС отличий никаких.
Приложение, SQL сревер и файловая система в передаче данных не участвуют.

Причем все полностью safe.
А если не полениться и прикрутить зависимые типы то ВМ на этапе компиляции проверит что все состояния протоколов обработаны. А если еще немного подумать то проверит что все обработано правильно.
Причем все будет работать с минимумом проверок ибо нафига если почти все доказано?

Здравствуйте, Pavel Dvorkin, Вы писали:

WH>>А еще я много думал на счет того как должны быть устроены правильные ОС.
PD>А то до тебя никто не думал.
Мелкософты думали. Сингулярити получилась.
Там конечно нужно выкинуть ту тупую ВМ что они использовали и спроектировать нормальную но направление ребята угадали очень не плохо.
А остальные куда то не туда думают.

PD>Объяснять я ничего не буду. Этот флейм тут уже не раз устраивался, да и Cyberax ответил,
Я ему тоже.

PD>я мог бы добавить, но и этого не буду.
Попробуй.

PD>Отмечу лишь маленькое такое передергивание. Если речь идет о файловых системах на основе SQL (вроде то ли закрытого, то ли нет проекта MS насчет SQL-файловой системы) — это может быть темой для реального проекта и темой для обсуждения.
И про них тоже. Ибо они все те же персистентные хранилища данных вот и все.

PD>А вот представление о MySQL как о дисковой подсистеме есть, извини, чушь несусветная.
С точки зрения приложения которое этот самый MySQL пользует совсем даже не чушь.

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

PD>Фантастическая способность с апломбом говорить , не разбираясь совершенно в сути вопроса.
Зеркало принести?

PD>Персистентное хранилище — и все.
А что это еще?

PD>Вся история и вся практика развития ОС и ФС за 50 лет коту под хвост.
Почему?

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

Здравствуйте, WolfHound, Вы писали:

C>>Файловая система тесно интегрирована с ядерным менеджером кэша и системой виртуальной памяти. Т.е. фичи типа sendfile могут работать очень быстро.
WH>1)Что мешает тоже самое сделать с SQL сервером?
Ничего особого. В теории.

WH>2)В правильных ОС фичи типа sendfile не нужны ибо они будут получатся автоматически.
Каким образом?

WH>ОСь аля сингулярити. Следи за руками:
WH>1)Приложение SQL среверу: Дай мне вон тот блоб на пару гигов.
WH>2)SQL сревер файловой системе: Заверни кусок того файла от сих до сих в поток.
WH>3)Файловая система драйверу винта: Вот тебе поток сложи в него такие то блоки.
WH>4)Файловая система SQL среверу: держи поток.
WH>5)SQL сревер приложению: держи поток.
WH>6)Приложение сетевому соединению: Отправь поток.
Мимо. Сетевому драйверу просто любой поток не подойдёт. Хотя бы потому, что в теории он может отдавать по байту в час, а нам нужна сразу как можно большая непрерывная область — чтоб можно было отдать её контроллеру DMA и забыть о ней.

Далее, как поток у нас будет информацию отдавать? Кто будет буффер для них распределять?

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

Линукс сейчас всё это делает, из-за чего возможно отдавать файлы из кэша прямо в сеть с нулевыми затратами. Буквально драйверу говорят "вот этот, этот и ещё вот этот блок отправить вот туда вот", драйвер как ему там нужно программирует сетевуху, запускает DMA и всё. Благодаря TCP offloading сейчас карточки вообще всё сами могут делать.

На Ethernet'е на это ещё всё можно наплевать, сейчас пара гигабит копирования процессоры не очень затруднит. А вот на FibreChannel или InfiniBand этот overhead уже весьма и весьма заметен.

Здравствуйте, Cyberax, Вы писали:

WH>>1)Что мешает тоже самое сделать с SQL сервером?
C>Ничего особого. В теории.
Расскажи это Дворкину. В его мире это всю историю ОС перечеркивает.

WH>>2)В правильных ОС фичи типа sendfile не нужны ибо они будут получатся автоматически.
C>Каким образом?
Я написал.

C>Мимо. Сетевому драйверу просто любой поток не подойдёт. Хотя бы потому, что в теории он может отдавать по байту в час, а нам нужна сразу как можно большая непрерывная область — чтоб можно было отдать её контроллеру DMA и забыть о ней.
Ты вообще читаешь то что я пишу?
Буквально в следующем абзаце я все расписал.
А ты его проигнорировал.

C>Далее, как поток у нас будет информацию отдавать? Кто будет буффер для них распределять?
Зачем распределять?
У нас в потоке уже буферы есть.
Вот прямо из них и отдавать.
На одном конце драйвер винта или там демон кеша складывает страници, а на другом драйвер сетевухи те же самые страници достает.
В чем проблема то?

C>Далее, чтоб отдать область напрямую контроллеру DMA — нужно чтобы все фрагменты были выровнены по границе страницы. А на время траснфера нужно ещё блокировать все эти страницы в физической памяти.
Ни разу не проблема.

C>Линукс сейчас всё это делает, из-за чего возможно отдавать файлы из кэша прямо в сеть с нулевыми затратами. Буквально драйверу говорят "вот этот, этот и ещё вот этот блок отправить вот туда вот", драйвер как ему там нужно программирует сетевуху, запускает DMA и всё. Благодаря TCP offloading сейчас карточки вообще всё сами могут делать.
Ну и тут все тоже самое.

Здравствуйте, WolfHound, Вы писали:

WH>>>1)Что мешает тоже самое сделать с SQL сервером?
C>>Ничего особого. В теории.
WH>Расскажи это Дворкину. В его мире это всю историю ОС перечеркивает.
Не, я боюсь с Дворкиным спорить

C>>Далее, как поток у нас будет информацию отдавать? Кто будет буффер для них распределять?
WH>Зачем распределять?
WH>У нас в потоке уже буферы есть.
Плохие буфферы.

Для полного DMA твой вариант со специальной обработкой невыровненного начала/конца не подойдёт. В случае с Infiniband я точно знаю, что он не умеет копировать половину страницы (за исключением последней) в scatter-gather режиме. Т.е. из-за невыровненного начала тебе придётся в две транзакции копирование делать.

Плохо.

А ешё если посмотреть взаимодействие всего этого с подсистемой VM... В общем, не так тут всё просто.

Здравствуйте, Cyberax, Вы писали:

WH>>У нас в потоке уже буферы есть.
C>Плохие буфферы.
Почему?

C>Для полного DMA твой вариант со специальной обработкой невыровненного начала/конца не подойдёт.
А что современные ОС в этом смысле чем-то отличаются?

C>В случае с Infiniband я точно знаю, что он не умеет копировать половину страницы (за исключением последней) в scatter-gather режиме. Т.е. из-за невыровненного начала тебе придётся в две транзакции копирование делать.
C>Плохо.
И в современных ОС будет абсолютно тоже самое.
Те отправляя HTTP ответ нам по любому нужно будет сформировать заголовки которые и в обычной ОС с высокой вероятностью будут не выровнены на границу страницы. А то и через какойнить writev будут отправлены.
А потом отправляем файло. А там уже все хорошо. Ибо один драйвер получает выровненые данные с винта, а другой те же самые данные без единого копирования отдает в сеть.
Короче не вижу причин по которым ситуация в данном случае в управляемой ОС будет хуже чем в не управляемой.
Почему может быть лучше я написал.

C>А ешё если посмотреть взаимодействие всего этого с подсистемой VM... В общем, не так тут всё просто.
А ВМ и ОСь тут одно и тоже. Так что ВМ будет сделана с учетом всей этой низкоуровневой возни.
В смысле реализация ВМ, а модель будет без единого гвоздя.

Здравствуйте, WolfHound, Вы писали:

C>>Плохие буфферы.
WH>Почему?
Выровненность не сохраняется. Впрочем, можно реализовать что-то типа NIO в Java. Это посложнее потоков будет, но там можно требования выровненности сохранять.

C>>Плохо.
WH>И в современных ОС будет абсолютно тоже самое.
WH>Те отправляя HTTP ответ нам по любому нужно будет сформировать заголовки которые и в обычной ОС с высокой вероятностью будут не выровнены на границу страницы. А то и через какойнить writev будут отправлены.
AFAIR, nginx их выравнивает.

WH>А потом отправляем файло. А там уже все хорошо. Ибо один драйвер получает выровненые данные с винта, а другой те же самые данные без единого копирования отдает в сеть.
WH>Короче не вижу причин по которым ситуация в данном случае в управляемой ОС будет хуже чем в не управляемой.
WH>Почему может быть лучше я написал.
Да, ты прав. Только абстракцию более мощную надо выбрать, чем поток.

C>>А ешё если посмотреть взаимодействие всего этого с подсистемой VM... В общем, не так тут всё просто.
WH>А ВМ и ОСь тут одно и тоже. Так что ВМ будет сделана с учетом всей этой низкоуровневой возни.
WH>В смысле реализация ВМ, а модель будет без единого гвоздя.
Не забывай, что в FS оно ещё и с файловым кэшем интегрировано. Т.е. при давлении на память менеджер VM лишние страницы будет выкидывать.

Здравствуйте, Cyberax, Вы писали:

C>Выровненность не сохраняется.
С какого перепугу?

C>AFAIR, nginx их выравнивает.
Рад за него.
А в случае с управляемой ОС можно реализовать поток так что он при записи будет склеивать маленькие буферы в большой выровненный буфер.

C>Да, ты прав. Только абстракцию более мощную надо выбрать, чем поток.
Не надо.
Ведь мы из потока можем забирать данные разными способами.
Можем сказать дай следующие Н байт.
А можем сказать дай следующий блок такого размера какой получился.
И все! Какие блоки сложили на одной стороне такие (или лучше за счет склеивания мелочи и хвостов не выровненных) получили на другой.

C>Не забывай, что в FS оно ещё и с файловым кэшем интегрировано. Т.е. при давлении на память менеджер VM лишние страницы будет выкидывать.
И в чем проблема?
В данном случае менеджер виртуальной памяти интегрирован в саму виртуальную машину и повязан с мусорщиком.

Здравствуйте, WolfHound, Вы писали:

C>>AFAIR, nginx их выравнивает.
WH>Рад за него.
WH>А в случае с управляемой ОС можно реализовать поток так что он при записи будет склеивать маленькие буферы в большой выровненный буфер.
Это вообще-то умеет делать и libc

C>>Да, ты прав. Только абстракцию более мощную надо выбрать, чем поток.
WH>Не надо.
WH>Ведь мы из потока можем забирать данные разными способами.
WH>Можем сказать дай следующие Н байт.
Вот это поток.

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

WH>И все! Какие блоки сложили на одной стороне такие (или лучше за счет склеивания мелочи и хвостов не выровненных) получили на другой.
Надо ещё управление буфферами туда пришпилить. Т.е. я могу сделать memory mapped file, взять от него буффер (который на уровне системы будет синхронизироваться с кэшем) и отдать его передавальщику в сеть. Передавальщик посмотрит, что буффер имеет все нужные возможности — и пойдёт по fastpath'у без всякого копирования.

C>>Не забывай, что в FS оно ещё и с файловым кэшем интегрировано. Т.е. при давлении на память менеджер VM лишние страницы будет выкидывать.
WH>И в чем проблема?
WH>В данном случае менеджер виртуальной памяти интегрирован в саму виртуальную машину и повязан с мусорщиком.
Как определять когда неплохо бы из кэша чего-нибудь выбросить?

Здравствуйте, Cyberax, Вы писали:

WH>>А можем сказать дай следующий блок такого размера какой получился.
C>А это уже не совсем поток.
Ну и пусть не совсем. Короче спор о терминах нужно послать лесом.
Главное что мы получаем все удобства потока и не теряем ни в скорости ни в безопасности.

C>Надо ещё управление буфферами туда пришпилить. Т.е. я могу сделать memory mapped file, взять от него буффер (который на уровне системы будет синхронизироваться с кэшем) и отдать его передавальщику в сеть. Передавальщик посмотрит, что буффер имеет все нужные возможности — и пойдёт по fastpath'у без всякого копирования.
Это само получится.
Ибо по любому нужно интегрировать менеджер виртуальной памяти и ФС. Там конечно есть скользкие моменты но ИМХО все решаемо. Особенно если не забывать включать голову.
А все что действительно нужно потоку это заниматься склейкой мелочи и хвостов.

C>Как определять когда неплохо бы из кэша чего-нибудь выбросить?
ХЗ. Я так с ходу всю СОь с нуля спроектировать не могу.
Но не думаю что возникнут неразрешимые проблемы.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Объяснять я ничего не буду. Этот флейм тут уже не раз устраивался, да и Cyberax ответил, я мог бы добавить, но и этого не буду.

Cyberax упомянул только оптимизации, но ничего принципиального. А оптимизации как известно имеют тенденцию устаревать и отсыхать. Вчера мы оптимизировали наши программы под 640 KB памяти, завтра будем оптимизировать под 640 ядер процессора.

Здравствуйте, Cyberax, Вы писали:
C>Плохие буфферы.
Прекрасные буферы. Главная их красота — в том, что не нужно заниматься каким-то особенным маршаллингом и договариваться о чём-то. Благодаря отсутствию аппаратной изоляции, адрес буфера можно безопасно передавать между приложениями и пользоваться им без малейших потерь.

C>Для полного DMA твой вариант со специальной обработкой невыровненного начала/конца не подойдёт.
А зачем нам полный DMA? Если мы отдаём empty.gif, то он со всеми хидерами вместе взятыми не займет и одной страницы; боттлнеком будет быстродействие сети.
А для мегабайтного pdf мы вполне можем себе позволить пару раз обратиться к драйверу сети — один раз запихать хидеры, другой раз запихать весь файл. Главное, что весь мегабайт уедет как есть — без копирования между адресными пространствами.
C>В случае с Infiniband я точно знаю, что он не умеет копировать половину страницы (за исключением последней) в scatter-gather режиме. Т.е. из-за невыровненного начала тебе придётся в две транзакции копирование делать.
Всё равно это бесконечно выгодно по сравнению с циклом file.Read(myBuffer, out readLength); socket.Send(myBuffer, readLength).
C>А ешё если посмотреть взаимодействие всего этого с подсистемой VM... В общем, не так тут всё просто.
Ага. Ну то есть получаем всего-то ничего 0.95 скорости света. По сравнению с первой космической. Ужас просто.

Здравствуйте, Sinclair, Вы писали:

C>>Плохие буфферы.
S>Прекрасные буферы. Главная их красота — в том, что не нужно заниматься каким-то особенным маршаллингом и договариваться о чём-то. Благодаря отсутствию аппаратной изоляции, адрес буфера можно безопасно передавать между приложениями и пользоваться им без малейших потерь.
Ладно, у меня ещё примеры есть Скажем, для графического ускорителя неплохо бы сразу уметь байндить текстуры (и прочие объекты, у нас же GPGPU и всё такое) в видеопамять.

Но там опять есть проблемы — нужно байндить их в специальную область физической памяти, отображаемую на видеопамять (GART Aperture), т.е. опять течёт абстракция. А ещё память в GART весьма странно ведёт себя с кэшированием — кэши надо явно сбрасывать (командой процессора cflush), иначе видеокарта их не увидит.

C>>Для полного DMA твой вариант со специальной обработкой невыровненного начала/конца не подойдёт.
S>А зачем нам полный DMA? Если мы отдаём empty.gif, то он со всеми хидерами вместе взятыми не займет и одной страницы; боттлнеком будет быстродействие сети.
А если мы занимаемся HPC (который сейчас пишут на суровом C++) и нам надо минимальную латентность иметь?

C>>В случае с Infiniband я точно знаю, что он не умеет копировать половину страницы (за исключением последней) в scatter-gather режиме. Т.е. из-за невыровненного начала тебе придётся в две транзакции копирование делать.
S>Всё равно это бесконечно выгодно по сравнению с циклом file.Read(myBuffer, out readLength); socket.Send(myBuffer, readLength).
Да кто же спорит-то? Но сейчас (да-да, вот прямо сейчас) в том же Линуксе это уже сделано нормально (с полным zero-copy в fastpath) и работает быстро. Но там и не пытались делать текущие абстракции.

C>>А ешё если посмотреть взаимодействие всего этого с подсистемой VM... В общем, не так тут всё просто.
S>Ага. Ну то есть получаем всего-то ничего 0.95 скорости света. По сравнению с первой космической. Ужас просто.
По сравнению с текущим 2*c...

Здравствуйте, Cyberax, Вы писали:
C>Ладно, у меня ещё примеры есть Скажем, для графического ускорителя неплохо бы сразу уметь байндить текстуры (и прочие объекты, у нас же GPGPU и всё такое) в видеопамять.
Не очень понятно, что такое "сразу".
C>Но там опять есть проблемы — нужно байндить их в специальную область физической памяти, отображаемую на видеопамять (GART Aperture), т.е. опять течёт абстракция.
Гм. Это как бэ проблемы драйвера видеокарты, разве нет? В том смысле, что он может озаботиться выделением текстуры таким образом, что нужный виртуальный адрес отмаплен внутрь апертуры. Тогда я могу делать вещи типа file.Read(myGARTBuffer) в своём приложениии, и обходиться минимумом копирований.

S>>А зачем нам полный DMA? Если мы отдаём empty.gif, то он со всеми хидерами вместе взятыми не займет и одной страницы; боттлнеком будет быстродействие сети.
C>А если мы занимаемся HPC (который сейчас пишут на суровом C++) и нам надо минимальную латентность иметь?
А какое отношение HPC имеет к сети? Если мы обращаемся к файлухе, то за DMA-friendly выравниванием будет следить её драйвер.

C>Да кто же спорит-то? Но сейчас (да-да, вот прямо сейчас) в том же Линуксе это уже сделано нормально (с полным zero-copy в fastpath) и работает быстро. Но там и не пытались делать текущие абстракции.

C>По сравнению с текущим 2*c...
Текущий 2*c, как я понял, мгновенно просасывает на сценариях, чуть выходящих за пределы sendfile. Для этого конкретного случая и в винде fastpath предусмотрен.
Речь-то идет о том, как юзермодным приложениям вроде SQL Server получить бенефит, аналогичный этим ядерным сервисам.

Здравствуйте, Cyberax, Вы писали:

C>Но там опять есть проблемы — нужно байндить их в специальную область физической памяти, отображаемую на видеопамять (GART Aperture), т.е. опять течёт абстракция. А ещё память в GART весьма странно ведёт себя с кэшированием — кэши надо явно сбрасывать (командой процессора cflush), иначе видеокарта их не увидит.
1)Приложение графической системе: Нужна память под текстуру.
2)Графическая система видеодрайверу: Нужна память под текстуру.
3)Видеодрайвер графической системе: Забирай.
4)Графическая система приложению: Забирай.
5)Приложение: Гружу текстуру.
6)Приложение графической системе: Забирай.
7)Графическая система видеодрайверу: Забирай.
8)Видеодрайвер графической системе: Текстура загружена.
9)Графическая система приложению: Текстура загружена.
И опять без единой протечки.
И при разборе полетов так будет со всем.

C>А если мы занимаемся HPC (который сейчас пишут на суровом C++) и нам надо минимальную латентность иметь?
Ты же вроде уже согласился что оно будет как минимум не хуже чем сейчас.

C>Да кто же спорит-то? Но сейчас (да-да, вот прямо сейчас) в том же Линуксе это уже сделано нормально (с полным zero-copy в fastpath) и работает быстро. Но там и не пытались делать текущие абстракции.
Опять 25. Куда и чего протекло?

Здравствуйте, Cyberax, Вы писали:

C>Но там опять есть проблемы — нужно байндить их в специальную область физической памяти, отображаемую на видеопамять (GART Aperture), т.е. опять течёт абстракция. А ещё память в GART весьма странно ведёт себя с кэшированием — кэши надо явно сбрасывать (командой процессора cflush), иначе видеокарта их не увидит.
Или даже так:
1)Приложение графической системе: Держи поток с текстурой.
2)Графическая система видеодрайверу: Держи поток с текстурой.
3)Видеодрайвер графической системе: Текстура загружена.
4)Графическая система приложению: Текстура загружена.

Здравствуйте, IT, Вы писали:

IT>Cyberax упомянул только оптимизации, но ничего принципиального. А оптимизации как известно имеют тенденцию устаревать и отсыхать. Вчера мы оптимизировали наши программы под 640 KB памяти, завтра будем оптимизировать под 640 ядер процессора.

Тот факт, что MS начала разработку SQL FS, говорит о том, что такая задача может быть поставлена. Вряд ли они бы начали эту разработку, не продумав идею.
Тот факт, что эта FS так и не появилась и теперь неясно, когда появится, говорит о том, что имеются , по-видимому, достаточно серьезные проблемы в ее реализации.

Обсуждать же вообще возможность такой FS в деталях я просто не имею никакого желания. Мои замечания относились просто к утверждениям WolfHound о MySQL, который к SQL FS и вообще к какой бы то ни было FS не имеет ни малейшего отношения.

Здравствуйте, WolfHound, Вы писали:

WH>Или даже так:
WH>1)Приложение графической системе: Держи поток с текстурой.
WH>2)Графическая система видеодрайверу: Держи поток с текстурой.
WH>3)Видеодрайвер графической системе: Текстура загружена.
WH>4)Графическая система приложению: Текстура загружена.
Вот примерно так попробовали сделать товарищи из Tungsten Graphics (только вместо потоков использовали асбтрактные буфферы), когда затеяли обобщённый менеджер памяти (TTM — Translation Table Map) для X-сервера. Фигня получилась. Тормозило всё из-за того, что слишком часто нужно сбрасывать кэши — так как на уровне менеджера памяти нельзя было понять откуда ноги растут у буфферов.

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

Или ещё вариант — для некоторых случаев нужно гарантированно иметь данные в памяти. То есть, к примеру, для некоторых IRQ-обработчиков нужно гарантировать, что страницы с данными будут точно готовы, а не будут лежать на диске или сервере на Марсе.

Здравствуйте, WolfHound, Вы писали:

C>>Но там опять есть проблемы — нужно байндить их в специальную область физической памяти, отображаемую на видеопамять (GART Aperture), т.е. опять течёт абстракция. А ещё память в GART весьма странно ведёт себя с кэшированием — кэши надо явно сбрасывать (командой процессора cflush), иначе видеокарта их не увидит.
WH>1)Приложение графической системе: Нужна память под текстуру.
WH>2)Графическая система видеодрайверу: Нужна память под текстуру.
WH>3)Видеодрайвер графической системе: Забирай.
WH>4)Графическая система приложению: Забирай.
WH>5)Приложение: Гружу текстуру.
WH>6)Приложение графической системе: Забирай.
Тут всё так.

WH>7)Графическая система видеодрайверу: Забирай.
WH>8)Видеодрайвер графической системе: Текстура загружена.
WH>9)Графическая система приложению: Текстура загружена.
А вот так делать уже нельзя. Команда "текстура загружена" должна сбросить кэш процессора, чтоб видеокарта увидела данные (а некэшируемая работа с памятью тормозит как рендеринг в software). А это дико дорого, нужно делать это массово. Кроме того, для чтения из текстурной области (если так захочется) нужно сбросить ещё кэш видеокарты.

А, там ещё веселуха есть. GART Aperture ограничен архитектурно на AGP 512 мегабайтами, так что если на карте более 512Мб, то используется переключение банков (...вспомним старый добрый Спектрум...). Так что у буфферов ещё будет признак "в системной памяти".

Так что стройная картинка вдруг обрастает нестройными подробностями.

C>>А если мы занимаемся HPC (который сейчас пишут на суровом C++) и нам надо минимальную латентность иметь?
WH>Ты же вроде уже согласился что оно будет как минимум не хуже чем сейчас.
Будет.

C>>Да кто же спорит-то? Но сейчас (да-да, вот прямо сейчас) в том же Линуксе это уже сделано нормально (с полным zero-copy в fastpath) и работает быстро. Но там и не пытались делать текущие абстракции.
WH>Опять 25. Куда и чего протекло?
Выравнивание страниц. Требование выравнивания надо передать на самый верхний уровень.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Тот факт, что MS начала разработку SQL FS, говорит о том, что такая задача может быть поставлена. Вряд ли они бы начали эту разработку, не продумав идею.
PD>Тот факт, что эта FS так и не появилась и теперь неясно, когда появится, говорит о том, что имеются , по-видимому, достаточно серьезные проблемы в ее реализации.
Тот факт, что появились FILESTREAMы в MS SQL, говорит о том, что проблем в реализации, собсно, нет. Нет потребности в таком ракурсе, который вначале казался актуальным.
PD>Обсуждать же вообще возможность такой FS в деталях я просто не имею никакого желания.
Это правильно. А то окажется, что современные SQL сервера вполне себе могут работать на том же уровне, что и FS.

PD>Мои замечания относились просто к утверждениям WolfHound о MySQL, который к SQL FS и вообще к какой бы то ни было FS не имеет ни малейшего отношения.
Какое трогательное неумение видеть общее за частностями.

Здравствуйте, Sinclair, Вы писали:

C>>Ладно, у меня ещё примеры есть Скажем, для графического ускорителя неплохо бы сразу уметь байндить текстуры (и прочие объекты, у нас же GPGPU и всё такое) в видеопамять.
S>Не очень понятно, что такое "сразу".
После создания, без лишних копирований.

C>>Но там опять есть проблемы — нужно байндить их в специальную область физической памяти, отображаемую на видеопамять (GART Aperture), т.е. опять течёт абстракция.
S>Гм. Это как бэ проблемы драйвера видеокарты, разве нет?
Нет. Если делать всё абстрактно, то буффер может выделить кто угодно.

S>В том смысле, что он может озаботиться выделением текстуры таким образом, что нужный виртуальный адрес отмаплен внутрь апертуры. Тогда я могу делать вещи типа file.Read(myGARTBuffer) в своём приложениии, и обходиться минимумом копирований.
А не получится...

C>>А если мы занимаемся HPC (который сейчас пишут на суровом C++) и нам надо минимальную латентность иметь?
S>А какое отношение HPC имеет к сети? Если мы обращаемся к файлухе, то за DMA-friendly выравниванием будет следить её драйвер.
Для кластеров в HPC нужны низколатентные сети.

C>>По сравнению с текущим 2*c...
S>Текущий 2*c, как я понял, мгновенно просасывает на сценариях, чуть выходящих за пределы sendfile. Для этого конкретного случая и в винде fastpath предусмотрен.
В Линуксе оно с помощью splice() работает для почти любых дескрипторов.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Мои замечания относились просто к утверждениям WolfHound о MySQL, который к SQL FS и вообще к какой бы то ни было FS не имеет ни малейшего отношения.
S>Какое трогательное неумение видеть общее за частностями.

Ну если для тебя вслед за WolfHound разница между приложением, реализующим SQL и хранение данных на его основе, и драйвером ФС, реализующим доступ к логическому диску — хоть NTFS, хоть FAT, хоть SQLFS есть лишь общее и частности — велкам в форум "Низкоуровневое программирование", объясни там всем, что разница между процессом и драйвером только в том. что драйвер работает в нулевом кольце, а MySQL есть подсистема управления дисками. Попробуй, интересно будет на реакцию тамошних жителей посмотреть.

Здравствуйте, Cyberax, Вы писали:

C>Или ещё вариант — для некоторых случаев нужно гарантированно иметь данные в памяти. То есть, к примеру, для некоторых IRQ-обработчиков нужно гарантировать, что страницы с данными будут точно готовы, а не будут лежать на диске или сервере на Марсе.

Маленький комментарий. В Windows это требование не связано с быстродействием, а является принципиальным. Если на высоких IRQL допустить подкачку страниц, то эта подкачка может вызвать прерывание, что приведет к дурной бесконечности. Поэтому при IRQL>=2 подкачка страниц запрещена.

Здравствуйте, Cyberax, Вы писали:

C>А вот так делать уже нельзя. Команда "текстура загружена" должна сбросить кэш процессора, чтоб видеокарта увидела данные (а некэшируемая работа с памятью тормозит как рендеринг в software). А это дико дорого, нужно делать это массово. Кроме того, для чтения из текстурной области (если так захочется) нужно сбросить ещё кэш видеокарты.
Кешь сбросит драйвер видюхи между пунктами 7 и 8.
А "текстура загружена" это не команда, а ответ приложению что все ОК.

C>А, там ещё веселуха есть. GART Aperture ограничен архитектурно на AGP 512 мегабайтами, так что если на карте более 512Мб, то используется переключение банков (...вспомним старый добрый Спектрум...). Так что у буфферов ещё будет признак "в системной памяти".
И чё?
Буфер выделяет драйвер по всем правилам.
Отдает приложению.
Приложение его заполняет и отдает драйверу.
При это система типов гарантирует что у приложения не останется ссылок на этот самый буфер.
Ну и где проблемы?

C>Так что стройная картинка вдруг обрастает нестройными подробностями.
В твоем воображении.

WH>>Ты же вроде уже согласился что оно будет как минимум не хуже чем сейчас.
C>Будет.
И что тогда опять споришь?

C>Выравнивание страниц. Требование выравнивания надо передать на самый верхний уровень.
Никуда оно не протекло.

Здравствуйте, WolfHound, Вы писали:

WH>Кешь сбросит драйвер видюхи между пунктами 7 и 8.
Нельзя так делать.

WH>А "текстура загружена" это не команда, а ответ приложению что все ОК.
Я так и понял.

C>>А, там ещё веселуха есть. GART Aperture ограничен архитектурно на AGP 512 мегабайтами, так что если на карте более 512Мб, то используется переключение банков (...вспомним старый добрый Спектрум...). Так что у буфферов ещё будет признак "в системной памяти".
WH>И чё?
WH>Буфер выделяет драйвер по всем правилам.
WH>Отдает приложению.
WH>Приложение его заполняет и отдает драйверу.
WH>При это система типов гарантирует что у приложения не останется ссылок на этот самый буфер.
WH>Ну и где проблемы?
Уже нет красивых потоков, а есть специальные буфферы. А ещё нужны мутируемые буфферы, в которые можно рисовать.

Я к чему это? К тому, что ради скорости придётся делать частные случаи. Одним из таких случаев является файловая система — там большое количество оптимизаций для хранения и работы с блоками данных. Попытки сделать что-то обобщённое вполне реальны, но обычно сильно тормозят.

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

Здравствуйте, Cyberax, Вы писали:

WH>>Кешь сбросит драйвер видюхи между пунктами 7 и 8.
C>Нельзя так делать.
Почему?

C>Уже нет красивых потоков, а есть специальные буфферы.
А куда они делись?
Там где были потоки там они и остались.
А тут естественное представление это буфер.
И тут сделан буфер.

C>А ещё нужны мутируемые буфферы, в которые можно рисовать.
Ты про DiractDraw? Так его даже мелкософты из новых версий DirectX выкинули.
Но если очень хочется то будет такой же диалог как в случае с текстурой.

C>Я к чему это? К тому, что ради скорости придётся делать частные случаи.
Не придется.

C>Одним из таких случаев является файловая система — там большое количество оптимизаций для хранения и работы с блоками данных. Попытки сделать что-то обобщённое вполне реальны, но обычно сильно тормозят.
Я вроде уже написал как все обобщить и ты согласился что все будет работать как минимум не хуже чем в современных ОС.
А теперь снова по кругу

C>Ты как мантру это повторяешь?
Это ты как мантру повторяешь. Протечки! Протечки!

C>Нужно получить как-то выровненный буффер. Как это сделать, если он может быть распределён как угодно?
Еще раз: Его выделит драйвер как надо.
В прикладной код буфер приедет уже выделенный так как надо.
Никаких протечек.

Если ты отправляешь HTTP ответ то тебе все равно придется отдельно отправлять заголовки и отдельно картинку.
В любой ОС.

Здравствуйте, WolfHound, Вы писали:

WH>>>Кешь сбросит драйвер видюхи между пунктами 7 и 8.
C>>Нельзя так делать.
WH>Почему?
Если на каждую текстуру кэш сбрасывать — задолбаешься.

(работа с кэшем CPU — вообще сейчас самое сложное в программировании видеокарт)

C>>А ещё нужны мутируемые буфферы, в которые можно рисовать.
WH>Ты про DiractDraw? Так его даже мелкософты из новых версий DirectX выкинули.
WH>Но если очень хочется то будет такой же диалог как в случае с текстурой.
И опять те же проблемы с кэшем. А ещё я сейчас смотрю на драйвер видеокарты — там бывает ещё и специальное некэшируемое копирование. И ещё sharing части данных между буфферами. Уууххх.

C>>Одним из таких случаев является файловая система — там большое количество оптимизаций для хранения и работы с блоками данных. Попытки сделать что-то обобщённое вполне реальны, но обычно сильно тормозят.
WH>Я вроде уже написал как все обобщить и ты согласился что все будет работать как минимум не хуже чем в современных ОС.
WH>А теперь снова по кругу
Только для данного случая. Я пока не уверен, что в общем случае это удастся.

C>>Нужно получить как-то выровненный буффер. Как это сделать, если он может быть распределён как угодно?
WH>Еще раз: Его выделит драйвер как надо.
WH>В прикладной код буфер приедет уже выделенный так как надо.
WH>Никаких протечек.
Тогда прикладной код должен заранее создавать буфферы, зная что они будет позднее использоваться в FS. Я про это и говорю.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Тот факт, что MS начала разработку SQL FS, говорит о том, что такая задача может быть поставлена. Вряд ли они бы начали эту разработку, не продумав идею.
PD>Тот факт, что эта FS так и не появилась и теперь неясно, когда появится, говорит о том, что имеются , по-видимому, достаточно серьезные проблемы в ее реализации.

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

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

Здравствуйте, IT, Вы писали:

PD>>Объяснять я ничего не буду. Этот флейм тут уже не раз устраивался, да и Cyberax ответил, я мог бы добавить, но и этого не буду.
IT>Cyberax упомянул только оптимизации, но ничего принципиального. А оптимизации как известно имеют тенденцию устаревать и отсыхать. Вчера мы оптимизировали наши программы под 640 KB памяти, завтра будем оптимизировать под 640 ядер процессора.
Кстати, а как там себя чувствует NUMA-aware аллокатор буфферов?

Здравствуйте, Cyberax, Вы писали:

C>Кстати, а как там себя чувствует NUMA-aware аллокатор буфферов?

Кто это такой?

Здравствуйте, Cyberax, Вы писали:

C>Если на каждую текстуру кэш сбрасывать — задолбаешься.
Это блин мелкие детали реализации.
Никто не мешает копить текстуры пока они не понадобятся, а потом сбросить один наз на всех кешь.

C>Только для данного случая. Я пока не уверен, что в общем случае это удастся.
Куда оно нахрен денется?
В самом худшем случае получится DirectX.
Что сильно сквозь DirectX драйверы протекают?

C>Тогда прикладной код должен заранее создавать буфферы, зная что они будет позднее использоваться в FS. Я про это и говорю.
Про FS уже ВСЕ обсудили и ты согласился что будет как минимум не хуже.
Блин. Ты хуже Дворкина. Соглашаешься, а через полтора сообщения выходишь на второй круг

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

C>А не получится...
С чего бы?

C>Для кластеров в HPC нужны низколатентные сети.
Про HPC я знаю слишком мало, чтобы осмысленно что-то обсуждать. Но что-то мне подсказывает, что только в очень экзотических сетях 1 лишний вызов DMA на операцию будет заметен на фоне стоимости трансфера через сеть. Всё-таки внутренняя шина обычно на порядок шустрее.

C>В Линуксе оно с помощью splice() работает для почти любых дескрипторов.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Тот факт, что MS начала разработку SQL FS, говорит о том, что такая задача может быть поставлена. Вряд ли они бы начали эту разработку, не продумав идею.
PD>>Тот факт, что эта FS так и не появилась и теперь неясно, когда появится, говорит о том, что имеются , по-видимому, достаточно серьезные проблемы в ее реализации.

IT>Этим делом в MS (тогда это было WinFS) занималась команда, о которой в MS уже ходят легенды. Эти парни загубили не одну интересную идею и в данный момент весьма успешно это делают с EF. WinFS таки даже появилась и вышла как отдельное дополнение, но кривыми ручками видимо сложно сделать что-то прямое. Вскоре её не стало даже как дополнения.

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

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

Здравствуйте, Sinclair, Вы писали:

C>>Нет. Если делать всё абстрактно, то буффер может выделить кто угодно.
S>Если делать всё абстрактно, то и производительность будет совершенно абстрактной. Никто не обещал полной прозрачности. А вот отсутствие межпроцессного маршаллинга никуда не денется.
Обещал WolfHound. Про то и речь идёт.

C>>Для кластеров в HPC нужны низколатентные сети.
S>Про HPC я знаю слишком мало, чтобы осмысленно что-то обсуждать. Но что-то мне подсказывает, что только в очень экзотических сетях 1 лишний вызов DMA на операцию будет заметен на фоне стоимости трансфера через сеть.
Очень даже заметен.

S>Всё-таки внутренняя шина обычно на порядок шустрее.
Часто всего лишь в разы.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Может, ты и прав в своем выводе (насчет кривых рук), но тут одно "но" есть. Если бы эта ФС была МС действительно нужна, то она, обнаружив, что команда ее разработчиков имеет кривые руки, разогнала бы ее и создала новую уже не с кривыми руками. Но не стала. Видимо, не так уж нужна.

Нужность — это не совсем то, что здесь обсуждается. С этим я как раз согласен. Нужна ли FS based on SQL? Лично мне нет.