[Q] TCP/IP as an internal application IPC

> MMU защищает память ядро от прог. Но ведь при переходе в kernel mode настройки MMU не меняются?

Только новые дескрипторы в cs и ds загружаются... Вообще говоря, это смена карты памяти.

> Как был vm split настроен так он и остался, не? tlb сбрасываться при сисколе не должен, я где-то про это читал.

> Вот почему ядро не может писать в память программы я не понимаю.

А почему оно не может? copy_to_user/copy_from_user - это всего лишь обёртки, умеющие корректно восстанавливаться после GPF. Можно и без них в память процесса лезть, но от OOPS уже не защищён.

> В L1 используются виртуальные адреса, поэтому он не может не 
> инвалидироваться при смене АП.

о каком семействе процессоров идет речь?

> А для чего сделано вот это? ((unsigned long)-1 + 1)

В надежде, что компилятор расширит тип для промежуточного вычисления. По-моему, не работает. Надо сразу, наверное, + 1.0 делать. rdtsc возвращает ts в двух регистрах.

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

1. tsc может через 0 обернуться; 2. у меня двухголовая машина, таск может смигрировать на другой проц, а там tsc не обязано таким же быть

> Ну и чтобы уменьшить ошибку округления лучше n делит на N в самом конце, не?

У ieee754-представления свои проблемы с точностью есть. И максимальное значение есть, на 200к циклах вылезал overflow. Это же не Common Lisp, который с натуральными дробями прозрачно умеет работать.

> о каком семействе процессоров идет речь?

О дефолтном :)

понятно, только, ихмо, ты померял не то. Эта штука показала сколько по времени в тактах занимает системный вызов write на сокете. А он всего лишь кладёт данные в sendbuf и когда они будут отправлены и сколько на это потратит времени ядро неизвестно. Тут, кстати, TCP_NODELAY неплохо воткнуть.

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

> а кто сделает теперь какой-нить пример локального IPC без участия ядра?

Никто не сделает.

> понятно, только, ихмо, ты померял не то. Эта штука показала сколько по времени в тактах занимает системный вызов write на сокете. А он всего лишь кладёт данные в sendbuf и когда они будут отправлены и сколько на это потратит времени ядро неизвестно.

Вместо 26к минимум стало 25к5 минимум. Не велика разница.

> Тут, кстати, TCP_NODELAY неплохо воткнуть.

А вот тут получилось интересно: 39-52к тактов вместо 26-32к. Т.е. в 1.5-2 раза тормознее.

> Лана, а кто сделает теперь какой-нить пример локального IPC без участия ядра? :) Я бы двухсвязный список влепил в качестве очереди...

Можно односвязнный (rope). Только надо как-то будить клиента, ждущего данные. По-идее, если на шедуллер не охота закладываться, то нужно использовать futex'ы, а это опять ядро ;) Но всё равно быстрее tcp будет. Или интереса ради разнести сервер с клиентов на разные процы, чтобы не спали, и проверять так. На досуге поковыряю.

>> а кто сделает теперь какой-нить пример локального IPC без участия ядра?

> Никто не сделает.

Я делал...

> Можно односвязнный (rope)

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

Есть стандартные средства по работе со списками в C? :). Неохота изобретать велосипед.

> ...нужно использовать futex'ы, а это опять ядро ;) ...

Футексы -- только _ИНОГДА_ ядро (когда без этого никак не обойтись), в отличие от TCP/IP, который проходит через ядро, с двойной буферизацией и созданием / очисткой кучи очередей.

>> Никто не сделает.

> Я делал...

Я говорил про "сделать", а не "делать" :)

> Футексы -- только _ИНОГДА_ ядро (когда без этого никак не обойтись)

Эээээ... Ты уверен?

> Есть стандартные средства по работе со списками в C? :). Неохота изобретать велосипед.

В glib.

http://en.wikipedia.org/wiki/Futex

Но таки нельзя сказать, что бы это были чисто юзерспейсовые объекты.

>> Футексы -- только _ИНОГДА_ ядро (когда без этого никак не обойтись)

> Эээээ... Ты уверен?

man 7 futex

(be not confused by man 2 futex)

Буквоед! :)

Ок, я раз 10 это _сделал_.

> man 7 futex

Хех, так самое-то интересное - это FUTEX_WAIT и FUTEX_WAKE. volatile в шаред мемори вместо со спинлоками и без всяких man 7 futex можно использовать.

Из юзерспейса нельзя без ядра сказать другому процессу, чтобы он _резко_ проснулся и начал молотить подготовленные нами данные. А трюки с yield() на CFS, говорят, как-то не так работают.

> Хех, так самое-то интересное - это FUTEX_WAIT и FUTEX_WAKE. volatile в шаред мемори вместо со спинлоками и без всяких man 7 futex можно использовать.

Конечно, я про это и говорю.

В NTPL POSIX мутексах всё это и сделано во взаимодействии с ядрёным футекс_колл. Они без нужды в ядре не уснут...

Согласись, pthread семантика не сложнее TCP/IP...

> А трюки с yield() на CFS, говорят, как-то не так работают.

ну как бы yield это тоже ядро
и какие могут быть трюки, если "нужный" процесс может быть в любом узле rb-дерева? ;)

> Есть стандартные средства по работе со списками в C? :)

советую посмореть linux/list.h
не стандартное стредство С, но весьма хорошее

> ну как бы yield это тоже ядро

Несомненно :) Это были рассуждения вслух о том, как быстрее поднять процесс, ожидающий от нас данные.

> и какие могут быть трюки, если "нужный" процесс может быть в любом узле rb-дерева? ;)

Трюк был в том, что очередь процессов с этим же приоритетом решедулилась раньше (потому что yield'ящий процесс от остатка своего таймслайса отказался). Сейчас такое проворачивать смысла нет, потому что CFS изничтожило таймслайсы.

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

> Почему тогда обычные программы в пространство ядра не могут писать? :)

В их таблицах другие разрешения, но адреса-то те же. Или я не вижу чего-то очевидного?

>>> а кто сделает теперь какой-нить пример локального IPC без участия ядра?

>> Никто не сделает.

> Я делал...

Зачем?

> Зачем?

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

Короче, времени нету писать очередной велосипед, сорри :).

> Зачем?

Моя ситуация была такая: есть N процессоров и N процессов. Надо максимально эффактивно реализовать IPC.

Очевидное решение -- юзерспейсные спинлоки.

> юзерспейсные спинлоки

Спинлоки годятся только когда предполагается, что почти всегда ждать не придётся, но гарантия всё же нужна. Как например для защиты какого-нибудь общего ресурса, который захватывается на короткое время. Если ставить спинлок для ожидания события, то ждущий будет кушать проц. Всё-таки ядрёный futex (pthread_mutex) лучше.

> есть N процессоров и N процессов. Надо максимально эффактивно реализовать IPC.

> Очевидное решение -- юзерспейсные спинлоки.

Но processor affinity указать всё равно надо (иначе ядро может может перебросить конкурирующие нити на одно ядро, и привет)? Вот и участие ядра :)

P.S. так ты ушел с ЛОРа или нет?

> Вот и участие ядра :) 

только IPC здесь не причем :)