https://www.opennet.dev/openforum/vsluhforumID3/52746.html Роберт Ватсон (Robert Watson) объявил (http://groups.google.com/group/mailing.freebsd.current/msg/8f757de4828133fe) о завершении четырехлетней работы по переводу сетевой подсистемы FreeBSD на более эффективную систему блокировок. В сетевой стек FreeBSD 8-CURRENT добавлено исправление, удаляющее поддержку признака IFF_NEEDSGIANT (http://wiki.freebsd.org/NetworkNeedsGiant), обеспечивающего работоспособность старого кода сетевых драйверов, использующего механизм глобальной блокировки (Giant lock). Иными словами, отныне все сетевые драйверы переведены на новую MPSAFE (Multi Processor Safe) систему блокировок, эффективную для моногопроцессорных и многоядерных систем.<br><br>URL: http://docs.freebsd.org/cgi/mid.cgi?alpine.BSF.2.00.0904182144320.34662<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=21330<br> https://www.opennet.dev/openforum/vsluhforumID3/52746.html#45 Wed, 22 Apr 2009 08:43:41 GMT &gt;да, сразу видно что вы ни разу не видели "эппловскую хрень". <br><br>Видел, видел. Только я-то отнюдь не работник культуры, мне интересна другая архитектура. :)<br> https://www.opennet.dev/openforum/vsluhforumID3/52746.html#44 Wed, 22 Apr 2009 01:10:10 GMT да, сразу видно что вы ни разу не видели "эппловскую хрень".<br> https://www.opennet.dev/openforum/vsluhforumID3/52746.html#43 Tue, 21 Apr 2009 10:44:25 GMT &gt;&gt;NetBSD тоже двигается в сторону SMP, но, похоже, более планомерно:<br>&gt;&gt;http://www.netbsd.org/~ad/smp/tasks.html <br>&gt;<br>&gt;Куда уж планомернее. 90% работы сделано. <br>&gt;Насколько хорошо -- можно посмотреть в NetBSD5_RC4. <br>&gt;И сделано на порядок быстрее, чем во FreeBSD, года за два примерно. <br>&gt;<br>&gt;Вместо ~8 у FreeBSD. Причина -- NetBSD-шники пошли другим путем, <br>&gt;наняли одного человека на full-time (ad@) и не стали полагаться <br>&gt;на в общем-то неопределенный результат работы волонтеров. <br><br>Я думаю тут ещё не последюю роль сыграла хорошо продуманная архитектура системы, хороший уровень абстракции от оборудования, чистота и компактность кода.<br> https://www.opennet.dev/openforum/vsluhforumID3/52746.html#42 Tue, 21 Apr 2009 10:36:35 GMT &gt;NetBSD тоже двигается в сторону SMP, но, похоже, более планомерно:<br>&gt;http://www.netbsd.org/~ad/smp/tasks.html <br><br>Куда уж планомернее. 90% работы сделано.<br>Насколько хорошо -- можно посмотреть в NetBSD5_RC4.<br>И сделано на порядок быстрее, чем во FreeBSD, года за два примерно.<br>Вместо ~8 у FreeBSD. Причина -- NetBSD-шники пошли другим путем,<br>наняли одного человека на full-time (ad@) и не стали полагаться<br>на в общем-то неопределенный результат работы волонтеров.<br> https://www.opennet.dev/openforum/vsluhforumID3/52746.html#41 Mon, 20 Apr 2009 12:03:18 GMT На opennet тоже было:<br>17.05.2008 Инициатива по устранению глобальных блокировок в Linux ядре<br>http://www.opennet.ru/opennews/art.shtml?num=15922<br> https://www.opennet.dev/openforum/vsluhforumID3/52746.html#40 Mon, 20 Apr 2009 10:51:04 GMT &gt;21-й век на дворе, а BSD еще только двигайются в сторону SMP... <br><br>Что есть -- то есть. В Linux не лучше:<br>"12 лет назад Linux стал поддерживать многопроцессорные системы. Тогда же для предотвращения "логических гонок" (race conditions) без существенного изменения драйверов и других частей ядра был введен Big Kernel Lock, как временная мера до появления более совершенных механизмов синхронизации. Однако с течением времени для уменьшения задержек (latency) реализация Big Kernel Lock усложнялась: например, было добавлено вытеснение (preemption).<br><br>Недавно Linus вернул реализацию Big Kernel Lock к старому варианту (spinlock), и тем самым потерялась возможность вытеснения. По его словам, единственным приемлемым способом избавиться от задержек является уничтожение Big Kernel Lock из всех 1300+ мест, в которых он используется. Однако, по оценкам Ingo Molnar, с текущими темпами этот процесс может занять порядка 10 лет. Причина: Big Kernel Lock слишком прозрачен. Теперь слишком легко, даже не подозревая об этом, до https://www.opennet.dev/openforum/vsluhforumID3/52746.html#39 Mon, 20 Apr 2009 10:06:36 GMT &gt;21-й век на дворе, а BSD еще только двигайются в сторону SMP... <br><br>Так расскажите же нам так же детально состояние других ОС. Например, Windows NT 7, или MacOS X... упс, эппловская хрень &#8212; это ведь тоже в некотором роде BSD. Трудно? Тогда (это уже без сарказма) хотя бы поделитесь хотя бы _столь_же_подробной_ информацией по Linux, обсудим. :)<br><br>Главное, не путайте поддержку и оптимизацию. ;)<br> https://www.opennet.dev/openforum/vsluhforumID3/52746.html#38 Mon, 20 Apr 2009 09:53:27 GMT 21-й век на дворе, а BSD еще только двигайются в сторону SMP...<br> https://www.opennet.dev/openforum/vsluhforumID3/52746.html#37 Mon, 20 Apr 2009 05:12:09 GMT &gt;В OpenBSD все еще есть ваши любимые гигантские блокировки. Пользуйтесь на здоровье. <br><br>Они и во фряхе ещё есть, только в других подсистемах. Кстати, если инфа по приведённой рядом ссылке http://wiki.freebsd.org/SMPTODO не устарела, то нельзя считать, что во FreeBSD полностью избавились от блокировок в сетевой подсистеме, так как как минимум netgraph ещё юзает non-MPSAFE интерфейс timeout().<br><br>В OpenBSD тоже движутся в сторону fine-grained блокировок, недавно, например, свежий коммит на эту тему:<br><br>CVSROOT:        /cvs<br>Module name:    src<br>Changes by:     oga@cvs.openbsd.org     2009/04/19 11:50:18<br><br>Modified files:<br>        sys/arch/amd64/amd64: softintr.c <br>        sys/arch/amd64/include: intr.h <br>        sys/arch/i386/i386: softintr.c <br>        sys/arch/i386/include: intr.h <br><br>Log message:<br>Switch the softinterrupt code on x86 over to mutexes instead of<br>simplelocks + splhigh().<br><br>First part of making it possible to make mpsafe softinterrupts.<br>