The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Сетевой стек FreeBSD окончательно простился с глобальными блокировками

19.04.2009 03:16

Роберт Ватсон (Robert Watson) объявил о завершении четырехлетней работы по переводу сетевой подсистемы FreeBSD на более эффективную систему блокировок. В сетевой стек FreeBSD 8-CURRENT добавлено исправление, удаляющее поддержку флага IFF_NEEDSGIANT, обеспечивающего работоспособность старого кода сетевых драйверов, использующего механизм глобальной блокировки (Giant lock). Иными словами, отныне все сетевые драйверы переведены на новую MPSAFE (Multi Processor Safe) систему блокировок, эффективную для многопроцессорных и многоядерных систем.

  1. Главная ссылка к новости (http://docs.freebsd.org/cgi/mi...)
  2. OpenNews: В FreeBSD-CURRENT включена новая реализация MPSAFE TTY
  3. OpenNews: Анонсирован релиз FreeBSD 7.1. Обзор новшеств
  4. OpenNews: Официально анонсирован релиз FreeBSD 7.0, обзор новшеств.
  5. OpenNews: Сетевая подсистема FreeBSD избавилась от глобальных блокировок
Автор новости: Аноним
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/21330-freebsd
Ключевые слова: freebsd, kernel, lock
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (26) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.6, Дмитрий Ю. Карпов (?), 12:48, 19/04/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мне кажется, зря они забросили поддержку версии 4.x - однопроцессорных систем достаточно много, да и на двухпроцессорных системах гигантские блокировки не затрудняли работу слишком сильно; зато более совершенная система блокировок сложнее, что приводит к увеличению затрат.
     
     
  • 2.18, RE_set (?), 15:10, 19/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Попробуй DragonFlyBSD она когда-то ответлилась от 4-й фряхи
     
     
  • 3.21, аноним (?), 15:45, 19/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Угу, но и в плане производительности DFBSD провалилась полностью, судя по тестам.
     
  • 3.22, аноним (?), 15:47, 19/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Сомневаюсь, в DF банально слишком мало народу и FreeBSD уже слишком ушла вперед, codebase значительно различаются. Поэтому стрекозу можно рассматривать только как полигон для image и hammer, ни о каком практическом ее использовании речи быть не может.
     
     
  • 4.26, yantux (??), 16:47, 19/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    А передрать они не могут?
     
     
  • 5.29, аноним (?), 18:48, 19/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Кто передрать, DF? Говорю же, код уже значительно различается и народу мало. Флаг им у руки, конечно.
     
  • 2.20, аноним (?), 15:44, 19/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Поддержку версии 4.x они забросили очень правильно, потому что, независимо от параллельности сетевого стека, она протухла полностью и абсолютно.

    > на двухпроцессорных системах гигантские блокировки не затрудняли работу слишком сильно

    Постеснялись бы такой бред писать.

     
     
  • 3.32, cvsup (ok), 22:26, 19/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > Поддержку версии 4.x они забросили очень правильно, потому что, независимо от параллельности сетевого стека, она протухла полностью и абсолютно.

    +1, забавно теперь читать текст анонсов тех лет об очередном выпуске из 4 ветки. "Вот теперь уж точно последний релиз", "самый самый последний релиз" и т.д.
    Была бы возможность - забросили бы куда раньше.

     
  • 2.33, sky (??), 22:41, 19/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    В OpenBSD все еще есть ваши любимые гигантские блокировки. Пользуйтесь на здоровье.
     
     
  • 3.37, PereresusNeVlezaetBuggy (ok), 09:12, 20/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >В 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:18

    Modified files:
            sys/arch/amd64/amd64: softintr.c
            sys/arch/amd64/include: intr.h
            sys/arch/i386/i386: softintr.c
            sys/arch/i386/include: intr.h

    Log message:
    Switch the softinterrupt code on x86 over to mutexes instead of
    simplelocks + splhigh().

    First part of making it possible to make mpsafe softinterrupts.

     

  • 1.9, zorro (??), 13:34, 19/04/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Отлично! Была проделана огромная работа. Которую Дилону только предстоит пройти..
     
  • 1.23, Осторожный (ok), 15:59, 19/04/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Избавились - это хорошо.
    Видимо ожидаемый летом релиз FreeBSD 8.0 будет уже без блокировок.
    А вот будет ли это в FreeBSD 7.3 ?
     
     
  • 2.34, infofarmer (ok), 02:41, 20/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    нет
     
     
  • 3.35, Осторожный (ok), 07:59, 20/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    А вот это не очень хорошо.
    Придется ждать FreeBSD 8.1
     

  • 1.28, crypt (??), 17:32, 19/04/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хорошо, конечно. В каких-то других (disk io?) подсистемах блокировки сохраняются?
     
     
  • 2.30, Имя (?), 19:28, 19/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    конечно сохранятся... куда же без них
     
  • 2.31, cvsup (ok), 22:23, 19/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    http://wiki.freebsd.org/SMPTODO
     
     
  • 3.36, www2 (??), 08:44, 20/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    NetBSD тоже двигается в сторону SMP, но, похоже, более планомерно: http://www.netbsd.org/~ad/smp/tasks.html
     
     
  • 4.38, Аноним (-), 13:53, 20/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    21-й век на дворе, а BSD еще только двигайются в сторону SMP...
     
     
  • 5.39, PereresusNeVlezaetBuggy (ok), 14:06, 20/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >21-й век на дворе, а BSD еще только двигайются в сторону SMP...

    Так расскажите же нам так же детально состояние других ОС. Например, Windows NT 7, или MacOS X... упс, эппловская хрень — это ведь тоже в некотором роде BSD. Трудно? Тогда (это уже без сарказма) хотя бы поделитесь хотя бы _столь_же_подробной_ информацией по Linux, обсудим. :)

    Главное, не путайте поддержку и оптимизацию. ;)

     
     
  • 6.44, Trouble (?), 05:10, 22/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    да, сразу видно что вы ни разу не видели "эппловскую хрень".
     
     
  • 7.45, PereresusNeVlezaetBuggy (ok), 12:43, 22/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >да, сразу видно что вы ни разу не видели "эппловскую хрень".

    Видел, видел. Только я-то отнюдь не работник культуры, мне интересна другая архитектура. :)

     
  • 5.40, iZEN (ok), 14:51, 20/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >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

     
     
  • 6.41, Аноним (-), 16:03, 20/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    На opennet тоже было:
    17.05.2008 Инициатива по устранению глобальных блокировок в Linux ядре
    https://www.opennet.ru/opennews/art.shtml?num=15922
     
  • 4.42, vle (ok), 14:36, 21/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >NetBSD тоже двигается в сторону SMP, но, похоже, более планомерно:
    >http://www.netbsd.org/~ad/smp/tasks.html

    Куда уж планомернее. 90% работы сделано.
    Насколько хорошо -- можно посмотреть в NetBSD5_RC4.
    И сделано на порядок быстрее, чем во FreeBSD, года за два примерно.
    Вместо ~8 у FreeBSD. Причина -- NetBSD-шники пошли другим путем,
    наняли одного человека на full-time (ad@) и не стали полагаться
    на в общем-то неопределенный результат работы волонтеров.

     
     
  • 5.43, www2 (??), 14:44, 21/04/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >>NetBSD тоже двигается в сторону SMP, но, похоже, более планомерно:
    >>http://www.netbsd.org/~ad/smp/tasks.html
    >
    >Куда уж планомернее. 90% работы сделано.
    >Насколько хорошо -- можно посмотреть в NetBSD5_RC4.
    >И сделано на порядок быстрее, чем во FreeBSD, года за два примерно.
    >
    >Вместо ~8 у FreeBSD. Причина -- NetBSD-шники пошли другим путем,
    >наняли одного человека на full-time (ad@) и не стали полагаться
    >на в общем-то неопределенный результат работы волонтеров.

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру