Роберт Ватсон (Robert Watson) объявил (http://groups.google.com/group/mailing.freebsd.current/msg/8...) о завершении четырехлетней работы по переводу сетевой подсистемы FreeBSD на более эффективную систему блокировок. В сетевой стек FreeBSD 8-CURRENT добавлено исправление, удаляющее поддержку признака IFF_NEEDSGIANT (http://wiki.freebsd.org/NetworkNeedsGiant), обеспечивающего работоспособность старого кода сетевых драйверов, использующего механизм глобальной блокировки (Giant lock). Иными словами, отныне все сетевые драйверы переведены на новую MPSAFE (Multi Processor Safe) систему блокировок, эффективную для моногопроцессорных и многоядерных систем.URL: http://docs.freebsd.org/cgi/mid.cgi?alpine.BSF.2.00.09041821...
Новость: http://www.opennet.me/opennews/art.shtml?num=21330
Мне кажется, зря они забросили поддержку версии 4.x - однопроцессорных систем достаточно много, да и на двухпроцессорных системах гигантские блокировки не затрудняли работу слишком сильно; зато более совершенная система блокировок сложнее, что приводит к увеличению затрат.
Попробуй DragonFlyBSD она когда-то ответлилась от 4-й фряхи
Угу, но и в плане производительности DFBSD провалилась полностью, судя по тестам.
Сомневаюсь, в DF банально слишком мало народу и FreeBSD уже слишком ушла вперед, codebase значительно различаются. Поэтому стрекозу можно рассматривать только как полигон для image и hammer, ни о каком практическом ее использовании речи быть не может.
А передрать они не могут?
Кто передрать, DF? Говорю же, код уже значительно различается и народу мало. Флаг им у руки, конечно.
Поддержку версии 4.x они забросили очень правильно, потому что, независимо от параллельности сетевого стека, она протухла полностью и абсолютно.> на двухпроцессорных системах гигантские блокировки не затрудняли работу слишком сильно
Постеснялись бы такой бред писать.
> Поддержку версии 4.x они забросили очень правильно, потому что, независимо от параллельности сетевого стека, она протухла полностью и абсолютно.+1, забавно теперь читать текст анонсов тех лет об очередном выпуске из 4 ветки. "Вот теперь уж точно последний релиз", "самый самый последний релиз" и т.д.
Была бы возможность - забросили бы куда раньше.
В OpenBSD все еще есть ваши любимые гигантские блокировки. Пользуйтесь на здоровье.
>В OpenBSD все еще есть ваши любимые гигантские блокировки. Пользуйтесь на здоровье.Они и во фряхе ещё есть, только в других подсистемах. Кстати, если инфа по приведённой рядом ссылке http://wiki.freebsd.org/SMPTODO не устарела, то нельзя считать, что во FreeBSD полностью избавились от блокировок в сетевой подсистеме, так как как минимум netgraph ещё юзает non-MPSAFE интерфейс timeout().
В OpenBSD тоже движутся в сторону fine-grained блокировок, недавно, например, свежий коммит на эту тему:
CVSROOT: /cvs
Module name: src
Changes by: oga@cvs.openbsd.org 2009/04/19 11:50:18Modified files:
sys/arch/amd64/amd64: softintr.c
sys/arch/amd64/include: intr.h
sys/arch/i386/i386: softintr.c
sys/arch/i386/include: intr.hLog message:
Switch the softinterrupt code on x86 over to mutexes instead of
simplelocks + splhigh().First part of making it possible to make mpsafe softinterrupts.
Отлично! Была проделана огромная работа. Которую Дилону только предстоит пройти..
Избавились - это хорошо.
Видимо ожидаемый летом релиз FreeBSD 8.0 будет уже без блокировок.
А вот будет ли это в FreeBSD 7.3 ?
нет
А вот это не очень хорошо.
Придется ждать FreeBSD 8.1
Хорошо, конечно. В каких-то других (disk io?) подсистемах блокировки сохраняются?
конечно сохранятся... куда же без них
http://wiki.freebsd.org/SMPTODO
NetBSD тоже двигается в сторону SMP, но, похоже, более планомерно: http://www.netbsd.org/~ad/smp/tasks.html
21-й век на дворе, а BSD еще только двигайются в сторону SMP...
>21-й век на дворе, а BSD еще только двигайются в сторону SMP...Так расскажите же нам так же детально состояние других ОС. Например, Windows NT 7, или MacOS X... упс, эппловская хрень — это ведь тоже в некотором роде BSD. Трудно? Тогда (это уже без сарказма) хотя бы поделитесь хотя бы _столь_же_подробной_ информацией по Linux, обсудим. :)
Главное, не путайте поддержку и оптимизацию. ;)
да, сразу видно что вы ни разу не видели "эппловскую хрень".
>да, сразу видно что вы ни разу не видели "эппловскую хрень".Видел, видел. Только я-то отнюдь не работник культуры, мне интересна другая архитектура. :)
>21-й век на дворе, а BSD еще только двигайются в сторону SMP...Что есть -- то есть. В Linux не лучше:
"12 лет назад Linux стал поддерживать многопроцессорные системы. Тогда же для предотвращения "логических гонок" (race conditions) без существенного изменения драйверов и других частей ядра был введен Big Kernel Lock, как временная мера до появления более совершенных механизмов синхронизации. Однако с течением времени для уменьшения задержек (latency) реализация Big Kernel Lock усложнялась: например, было добавлено вытеснение (preemption).Недавно Linus вернул реализацию Big Kernel Lock к старому варианту (spinlock), и тем самым потерялась возможность вытеснения. По его словам, единственным приемлемым способом избавиться от задержек является уничтожение Big Kernel Lock из всех 1300+ мест, в которых он используется. Однако, по оценкам Ingo Molnar, с текущими темпами этот процесс может занять порядка 10 лет. Причина: Big Kernel Lock слишком прозрачен. Теперь слишком легко, даже не подозревая об этом, добавить код, который захватывает BKL, и для большинства строк кода никто наверняка не знает, захвачен он в данной строке или нет. Кроме того, автоматическая проверка вложенности блокировок (lockdep) не знает о Big Kernel Lock, и поэтому слишком просто создать труднообнаружимый deadlock.
Для ускорения процесса удаления Big Kernel Lock Ingo Molnar создал git-дерево, в котором Big Kernel Lock стал более "видимым" (добавлены отладочные средства и поддержка lockdep), и его использование удалено из основного кода ядра."
Новость: http://lkml.org/lkml/2008/5/14/324
Обсуждение: http://www.linux.org.ru/view-message.jsp?msgid=2744340
На opennet тоже было:
17.05.2008 Инициатива по устранению глобальных блокировок в Linux ядре
http://www.opennet.me/opennews/art.shtml?num=15922
>NetBSD тоже двигается в сторону SMP, но, похоже, более планомерно:
>http://www.netbsd.org/~ad/smp/tasks.htmlКуда уж планомернее. 90% работы сделано.
Насколько хорошо -- можно посмотреть в NetBSD5_RC4.
И сделано на порядок быстрее, чем во FreeBSD, года за два примерно.
Вместо ~8 у FreeBSD. Причина -- NetBSD-шники пошли другим путем,
наняли одного человека на full-time (ad@) и не стали полагаться
на в общем-то неопределенный результат работы волонтеров.
>>NetBSD тоже двигается в сторону SMP, но, похоже, более планомерно:
>>http://www.netbsd.org/~ad/smp/tasks.html
>
>Куда уж планомернее. 90% работы сделано.
>Насколько хорошо -- можно посмотреть в NetBSD5_RC4.
>И сделано на порядок быстрее, чем во FreeBSD, года за два примерно.
>
>Вместо ~8 у FreeBSD. Причина -- NetBSD-шники пошли другим путем,
>наняли одного человека на full-time (ad@) и не стали полагаться
>на в общем-то неопределенный результат работы волонтеров.Я думаю тут ещё не последюю роль сыграла хорошо продуманная архитектура системы, хороший уровень абстракции от оборудования, чистота и компактность кода.