вот и я не хочу тут велосипед, благо всё кроме кривой у нас есть

Угу. Потому что попытки генерализации приводят к мострам типа crypto api. Где ты создаёшь сокет, через setsockopt конфигурируешь и потом начинается цирк. Например, если там хеши, то пишем в сокет сырые данные, а чтение возвращает digest. А потом начинается боль с aio, zero copy и o_nonblock. В итоге, нормально использовать очень неудобно.

ОЙ... #ZFS OpenZFS Feature Matrix https://docs.google.com/spreadsheets/d/1CFapSYxA5QRFYy5k6ge3FutU7zbAWbaeGN2nKVXgxCI/edit#gid=0 https://www.youtube.com/watch?v=2Bi0ZicXEz0

Это типа в Linux ZFS в лучшем состоянии чем у нас?

ну... пилило бы его у нас не три калеки, а три отдела, чего бы ему не быть лучше :)

угу

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

а какие-нибудь крупные фирмы имеют прогеров, которые контрибутят в FreeBSD? У Линукса вроде бы такие работники есть

ясное дело. да и врождённые дефекты в наличии.

а какие-нибудь крупные фирмы имеют прогеров, которые контрибутят в FreeBSD? У Линукса вроде бы такие работники есть

есть. типа Juniper, Netflix, Yandex. но ограниченно.

У juniper фря :). Еще забыл nintendo

и шо толку с той нинтенды?

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

Спасибо

Так. А SSE и прочий AVX у нас в ядре нельзя, да?

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

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

Точно? -mno-mmx -mno-sse -msoft-float

в ядре нельзя FPU

в ядре нельзя FPU

Вот я и смотрю.

я не знаю точно, SSE и пр. относится к FPU номинально или нет

А есть планы что бы было можно? Linux как-то справляется. Это, наверное, на hackers@ надо идти

Так. А что у нас вместо rcu? epoch(9)?

А есть планы что бы было можно? Linux как-то справляется. Это, наверное, на hackers@ надо идти

а загуглить по тому же листу сначала не пробовал?

@dmitryluhtionov если склероз не изменяет, тоже по чему то такому ядерному страдал, сори если ошибся :)

а загуглить по тому же листу сначала не пробовал?

нет ещё

А кто у нас сейчас за Intel? В MAINTAINERS указан erj@ но очень давно туда вписан.

их толпа, а толку мало

а есть тут кто-то, у кого болит от того что в stateful ipfw стейты грохаются при удалении правил?

звучит как предложение по улучшению :-)

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

А никто с такой странностью не сталкивался: uwsgi за nginx, всё хорошо, но если uwsgi отвечает больше чем за ~1.2 секунды откуда-то берется дополнительная задержка до 2 секунд

А как бы мне в out of tree модуле (который, однако, использует .include <bsd.kmod.mk>) сослаться на файл в ${SYSDIR}? Если просто его добавить в SRCS то make пытается и объектник создать прямо там, в ${SYSDIR}, на что у него, конечно, нет прав.

.PATH

.PATH

Чо-та я не то с ним делаю, похоже. Не ищет :-\ И make -V .PATH добавленное не показывает!

Хотя казалось бы, ну где там можно ошибиться — .PATH: <path>

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

запоминает опкод?

Хм. А добавление .PATH: /mnt работает

ну, двоеточие потерял?)

ну, двоеточие потерял?)

Да не, не потерял!

И make -V .PATH добавленное не показывает! разве?)

Такое впечатление, что SYSDIR выставляется ПОСЛЕ отработки .PATH

Т.е. что в момент выполнения .PATH: путь невалидный и он скипается

Ага

Если выписать /usr/src/sys вместо ${SYSPATH} то работает

SYSPATH в bsd.kmod.mk определяется слишком поздно. :-\

И поддериктории make всё равно сам не создаёт :-(

А никто с такой странностью не сталкивался: uwsgi за nginx, всё хорошо, но если uwsgi отвечает больше чем за ~1.2 секунды откуда-то берется дополнительная задержка до 2 секунд

а как эти 2 секунды измараются - $upstream_response_time в логах nginx при этом какое?

я хотел это добавить в лог но обломался, он не знает такой переменной. как я понял, это только к upstream относится, а у меня uwsgi

запоминает опкод?

https://reviews.freebsd.org/D17532

я хотел это добавить в лог но обломался, он не знает такой переменной. как я понял, это только к upstream относится, а у меня uwsgi

uWSGI тоже может быть апстримом

если по http отвечать будет?

да, либо nginx -> nginx <-> uwsgi.sock

если эти nginx <-> uwsgi.sock много

А никто с такой странностью не сталкивался: uwsgi за nginx, всё хорошо, но если uwsgi отвечает больше чем за ~1.2 секунды откуда-то берется дополнительная задержка до 2 секунд

это классно, на самом деле ? у нас тоже такая проблема была, но я ушел из той компании, не знаю решили или нет

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

а есть какой-нибудь cli uwsgi клиент?

А как вместе живут очереди и пакетов и CK в ядре? Что-то mbufq ниифнга не потокобезопасен, как я посмотрю. Как нынче правильно работать с очередями mbuf'ов в многопоточной ситуации? @bu7cher ?

а есть какой-нибудь cli uwsgi клиент?

так кто мешает напрямую обращаться к нему?

склонить код, http-socket включить

А как вместе живут очереди и пакетов и CK в ядре? Что-то mbufq ниифнга не потокобезопасен, как я посмотрю. Как нынче правильно работать с очередями mbuf'ов в многопоточной ситуации? @bu7cher ?

придумай

придумай

Ну то есть, общепринятого паттерна нет?

Я именно потому и спрашиваю — что если есть какой-то общепринятый метод, что бы велосипед не изобретать. Так-то я возьму CK'шную реализацию queue.h, кажется должно работать.

склонить код, http-socket включить

я хотел прямо в проде проверить, чтобы сразу понять uwsgi это или nginx

опасный ты ?

я хотел это добавить в лог но обломался, он не знает такой переменной. как я понял, это только к upstream относится, а у меня uwsgi

а, точно это другой модуль. По идее в ngx_http_uwsgi_module должны быть аналогичные переменные, но в документации их нет

ERROR: S client not available

во-во

CKшная реализация queue не гарантирует тебе ничего в многопоточном окружении, она только позволяет некоторые вещи сделать lockless, но это тоже ещё нужно придумать

CKшная реализация queue не гарантирует тебе ничего в многопоточном окружении, она только позволяет некоторые вещи сделать lockless, но это тоже ещё нужно придумать

Стоп. Она гарантирует SPMC, если верить документации

@AMDmi3 можно попробовать отдельно upstream определить в конфигурации: The ngx_http_upstream_module module is used to define groups of servers that can be referenced by the proxy_pass, fastcgi_pass, uwsgi_pass тогда может переменные $upstream_ будут доступны.

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

а-а, можно

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

SPMC даёт мне достать голову очереди и быть уверенным, что я единственный, кто её достал, нет? Ну, или это не SPMC нифига.

А, блин, там нет операции dequeue. Ну что за жизнь

Что, во всём ядре нигде нет очереди пакетов что бы с минимумом локов, подсмотреть негде?

Главное, ну написать-то такую очередь я могу (в очередной раз), но я не верю, что этот велосипед надо изобретать

драйверы обычно используют кольцевые буферы

buf_ring, mp_ring

драйверы обычно используют кольцевые буферы

Ну то есть, ограниченные очереди. Что правильно.

Ага, посмотрю на них.

а как эти 2 секунды измараются - $upstream_response_time в логах nginx при этом какое?

upstream_response_time правильный, т.е. без дополнительной задержки

локально что-то пока не повторяется

можно еще $request_time туда же логгировать - время в течение которого клиент общался с nginx и за одно $tcpinfo_rtt (оно пишется в микросекундах) чтобы видеть насколько медленная у клиента сеть

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

клиенту т. е. браузеру? А если curl-ом wget-ом потестировать? И нет ли там по дороге прозрачного прокси.

клиенту т.е. и браузеру и курлу и чему угодно. я повторил это запустив ещё один nginx на той же машине. что-то там не так с kevent

вот такой интересный график

Vova Okhrimenko будет жить. Поприветствуем!

Это офигенно. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231402

Ещё пара аналогичных PR, везде получается, что qt5-network ломается при наличии vlan-интерфейсов

QT для меня большая загадка. Он занимает места больше чем свежая установка винды. ЧТО ОН ТАКОЕ?!

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

гтк не меньше небось. И вообще он марсианский какой-то. Есть мнение, что хорошую вещь "г" не назовут

у них есть там какая то хрень, очень толстая и долго компиляемая

Началась вся эта потеха, по-моему, с qt5-5.11. Можно, конечно, откатить qt5-порты до 5.10 и portmaster -a. Но это больно и не хочется. Попробовать, что ли, qt5-* в jail запихнуть...

Хотя слабо себе представляю, как потом из jail'а тот же telegram-desktop в хост-иксы запускать. Не ssh-туннелем же :(