The OpenNET Project / Index page

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

В ядро FreeBSD добавлена поддержка счётчиков PCPU

11.04.2013 17:48

Глеб Смирнов (glebius@) добавил в ядро FreeBSD 10-CURRENT новый API для работы со счётчиками — counter(9). Счётчики являются частью инструментария сбора статистики и телеметрии во время работы ядра и системных компонентов и представляют собой структуры данных в оперативной памяти, значения в которых изменяются при наступлении тех или иных событий. К примеру, счётчики для подсчёта полученных и отброшенных сетевых пакетов, счётчик числа обнаруженных некорректных данных в подсистеме ввода-вывода и т.д..

В многопроцессорной многопоточной системе с большим количеством счётчиков возникает проблема конкуренции вычислительных потоков за монопольный доступ и корректное изменение значения счётчика. Обычное решение этой проблемы — монитор объекта счётчика через операцию блокировки шины памяти (atomic(9)) и предоставление монопольного доступа к счётчику одному из конкурирующих потоков для его инкремента. Но при таком способе ухудшается быстродействие в многозадачной среде: сбрасываются кэши процессорных ядер из-за недействительных значений счётчика, находящихся в их кэшах, с последующей перезагрузкой актуального значения счётчика из оперативной памяти в кэш процессора.

Новый API по-своему решает проблему актуализации счётчиков для всех заинтересованных потоков выполнения. Так, для каждого ядра процессора выделяется собственная область памяти, а структуры данных счётчиков мультиплицируются в эти области и не перекрывают друг друга. Теперь каждому ядру соответствует своя копия определённого счётчика, а каждое ядро изменяет только свою структуру данных счётчиков. Блокировка шины памяти для монопольного доступа потоков к счётчику больше не нужна. Чтобы обновить счётчик вычислительному потоку, ему нужно получить адрес счётчика в памяти ядра, на котором он выполняется, и произвести его изменение.

Для того, чтобы в это время контекст не мигрировал на другое ядро, используются критические секции (не на всех архитектурах это необходимо и часто удаётся избежать использования критических секций). В частности, на основной архитектуре FreeBSD — amd64 — обновление счётчика осуществляется в одну процессорную инструкцию! Для считывания значение счётчика, нужно просто сложить значения копий счётчика со всех ядер. Ну и объём памяти, занимаемый счётчиком, конечно же стал в несколько раз больше — в прямой зависимости от числа ядер процессоров.

Результаты:

  • В ряде тестов новые счётчики показывают повышение производительности примерно на 63% по сравнению с обычной операцией инкремента, но при этом нет потерь данных, а обычный инкремент теряет 98% данных;
  • В сравнении с атомарными инкрементами новые счётчики в 22 раза быстрее;
  • На реальных тестах по приёму сетевого трафика замена счётчиков IP-статистики приводит к снижению нагрузки на CPU примерно на 50%.


  1. Главная ссылка к новости (http://bu7cher.blogspot.ru/201...)
Автор новости: iZEN
Тип: К сведению
Короткая ссылка: https://opennet.ru/36669-freebsd
Ключевые слова: freebsd, kernel, counters
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (33) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, iZEN (ok), 18:51, 11/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –11 +/
    http://zet-news.ru/img/userfiles/images/0000ebae.jpg

    Вот.

     
     
  • 2.3, хрюкотающий зелюк (?), 19:37, 11/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не ты ли прыгать от радости должен что во фре что-то быстрее стало?
     

  • 1.2, IMHO (?), 19:29, 11/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    а тесты похороникса все равно напишут что тормозит ))))
     
     
  • 2.6, Аноним (-), 20:17, 11/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    в bsd главое ядра и не любит больше потоков чем цпу,
    линукс любит много потоков и не любит от количества цпу
     
     
  • 3.8, Аноним (-), 21:21, 11/04/2013 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Вывод: в бзде не осилили написать нормальный планировщик процессорного времени.

    Хотя в форониксовых бенчах факапы обычно потому что или компилится античным gcc 4.2, который по оптимизации vs 4.7 сильно проигрывает, или того хуже шлангом, который не только погано оптимизирует но и OpenMP хронически не умеет. А это сразу слив в несколько раз на пакетах типа GraphicsMagic'а и подобных, использующих OpenMP.

     
     
  • 4.11, Аноним (-), 21:38, 11/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    OpenMP костыль, предпочитаем векторизацию cpp кода

    http://ru.wikipedia.org/wiki/Векторизация%20(параллельные%20вычисле)

     
     
  • 5.23, Аноним (-), 08:39, 12/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > OpenMP костыль, предпочитаем векторизацию cpp кода

    Вот только в шланге 3.3 грозились таки его сделать. Ибо без него феерический слив в куче реально существующих программ. Дайте угадаю, он после этого сразу перестанет быть костылем, да? :).

    > http://ru.wikipedia.org/wiki/Векторизация%20(параллельные%20вычисле)

    Вику читать умеете. Малацца, возьмите с полки пирожок.

     
  • 4.12, iZEN (ok), 22:08, 11/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Вывод: в бзде не осилили написать нормальный планировщик процессорного времени.

    Зато в FreeBSD нет лагов курсора мышки при длительном копировании файлов с одного носителя на другой. Воспроизведение Full HD фильмов не нарушается, если в текстовой консоли идёт компиляция в несколько потоков.

    > Хотя в форониксовых бенчах факапы обычно потому что или компилится античным gcc
    > 4.2, который по оптимизации vs 4.7 сильно проигрывает,

    LLVM/Clang 3.2 в системе FreeBSD 9.1 производит код, который по скорости исполнения сравнялся с GCC 4.6. Кстати, во FreeBSD 8.x его можно поставить из порта, если нужно собрать приложения.

    > или того хуже шлангом, который не только погано оптимизирует но и OpenMP хронически не умеет.

    Много ли где поддерживается OpenMP? Перечислите ПО, где оно жизненно необходимо.

    > А это сразу слив в несколько раз на пакетах типа GraphicsMagic'а и подобных, использующих OpenMP.

    Ссылку?

     
     
  • 5.16, pavlinux (ok), 00:42, 12/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Зато в FreeBSD нет лагов курсора мышки при длительном копировании файлов с одного носителя
    > на другой. Воспроизведение Full HD фильмов не нарушается, если в текстовой консоли идёт
    > компиляция в несколько потоков.

    Давно линух-то видел?

    make -j128 & mplayer Private-17_1920x1080.mkv, и ещё дропбокс чёй-то в фоне синхронзирует.

     
     
  • 6.18, iZEN (ok), 01:02, 12/04/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> Зато в FreeBSD нет лагов курсора мышки при длительном копировании файлов с одного носителя
    >> на другой. Воспроизведение Full HD фильмов не нарушается, если в текстовой консоли идёт
    >> компиляция в несколько потоков.
    > Давно линух-то видел?

    Каждый день вижу.

    > make -j128 & mplayer Private-17_1920x1080.mkv, и ещё дропбокс чёй-то в фоне синхронзирует.

    Повтори это на компе 5 летней давности с одной из последних стабильных версий ядра Linux — расскажешь.


     
     
  • 7.22, BF (?), 07:51, 12/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >Каждый день вижу.

    Интересно где? На работе, где у тебя везде windows, или дома, где у тебя по слухам freeBSD

     
  • 7.29, цирроз (ok), 10:51, 12/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    ты даже не в курсе, что для такого параметра нужно ещё поболе памяти.
    так что будет работать и на Core 2 пятилетней давности. ну и к чему было сказано про "с одной из последних стабильных версий ядра Linux"? наверное, потому что ты - теоретик и неадекватный фанатик BSD. У меня среди подопечных где-то Mobile Celeron есть (тактовая 1.2GHz), на котором 3.8-6 ядро. напомнить год, когда эти процессоры делали?
     
  • 7.33, devl547 (ok), 13:41, 12/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >Повтори это на компе 5 летней давности с одной из последних стабильных версий ядра Linux — расскажешь.

    Acer Extensa 5210 - T5600@1.83, 2 гига оперы и хард на 5400.
    Повторил - не тормозит.

    >Каждый день вижу.

    На скриншотах?

    >LLVM/Clang 3.2 в системе FreeBSD 9.1 производит код, который по скорости исполнения сравнялся с GCC 4.6

    Странно. А на остальных системах (не FreeBSD) шланг сливает процентов на 10-15 в однопотоке. И это не считая мест, где оно может в 2-3 раза более медленный код выдавать.

     
  • 7.37, pavlinux (ok), 17:40, 12/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Повтори это на компе 5 летней давности ...

    # dmidecode  | less

    Handle 0x0000, DMI type 0, 20 bytes
    BIOS Information
            Vendor: Phoenix Technologies Ltd.
            Version: 2004Q3                      # чорт, почти 9-летней давности, ...
            Release Date: 11/18/2008
            Address: 0xE69B0
            Runtime Size: 104016 bytes
            ROM Size: 1024 kB

    System Information
            Manufacturer: TYAN Computer Corp.
            Product Name: S2895
            Version: TYAN Thunder K8WE S2895
            Serial Number: 0123456789
            UUID: Not Settable
            Wake-up Type: Power Switch
    ...
    > ... с одной из последних стабильных версий ядра Linux — расскажешь.

    # uname -a
    Linux suse64 3.2.43-plx #2 SMP PREEMPT RT Thu Apr 11 01:17:28 MSK 2013 x86_64 x86_64 x86_64 GNU/Linux

    ---

    Скажу боле, до этого у меня стоят Adaptec ASC-29320 и все винты на Ultra320 SCSI,
    любимый всеми троллями баг #12309 вообще никак непроявлялся. И все адекватные уже
    знают, что это косяк SATA архитектуры, тут ни ось, ни производитель ничё сделать
    не могут. Ну увеличели make -j до 128, ну и чё?!

    Можно так же потроллить на предмет, "Вы лузеры", Linx + SCSI SSD, со 128Gb RAM
    и make -j10000  в лёгкую работает, Вывод: BSD - говно!".


      

     
  • 5.24, Аноним (-), 08:51, 12/04/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Зато в FreeBSD нет лагов курсора мышки при длительном копировании файлов с
    > одного носителя на другой. Воспроизведение Full HD фильмов не нарушается, если
    > в текстовой консоли идёт компиляция в несколько потоков.

    Так у меня и в линуксе так же.

    > LLVM/Clang 3.2 в системе FreeBSD 9.1 производит код, который по скорости исполнения
    > сравнялся с GCC 4.6.

    Бенчи на форониксе этот тезис в очередной раз не подтвердили. Особенно фееричный слив на софте с OpenMP, там буквально по числу ядер просёр. В шланге 3.3 вроде как грозились его все-таки реализовать, но сейчас то у вас попа голая. Да и в целом по оптимизации шланг явно хуже.

    > Кстати, во FreeBSD 8.x его можно поставить из порта, если нужно собрать приложения.

    А кому кроме сектантов нужна лишняя возня?

    >> или того хуже шлангом, который не только погано оптимизирует но и OpenMP хронически не умеет.
    > Много ли где поддерживается OpenMP? Перечислите ПО, где оно жизненно необходимо.

    Смотря что понимать под жизненно необходимо. Без него ряд софта просто будет в эн раз тормознее, по числу ядер.

    >> А это сразу слив в несколько раз на пакетах типа GraphicsMagic'а и подобных,
    >> использующих OpenMP.
    > Ссылку?

    Фороникс. И его бенчи. И коменты к ним, где какие-то клоуны аж просили не делать :) бенчи с openmp xD. А то слив, видите ли.

     
     
  • 6.28, Клыкастый (ok), 09:26, 12/04/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Бенчи на форониксе этот тезис в очередной раз не подтвердили. Особенно фееричный слив на софте с OpenMP

    Хорошие бенчи. Берём софт заточеный под OpenMP и сравниваем. Собраный без OpenMP - медленнее, ибо в один поток. Аплодисменты идиотов идиотам.

     
  • 4.39, _yurkis__ (?), 20:21, 12/04/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Хотя в форониксовых бенчах факапы обычно потому что или компилится античным gcc 4.2, который по оптимизации vs 4.7 сильно проигрывает, или того хуже шлангом, который не только погано оптимизирует но и OpenMP хронически не умеет.

    Тем не менее БЗДЯ 9.1 STABLE собранная clang 3.2 все- таки процентов на 10 как минимум шустрее нежели собранная gcc 4.2.
    Плюс у шланга есть все шансы догнать gcc уже в обозримом будущем.

    Да, насчет OpenMP. Я конечно не обравдываю шланг, но все же насколько часто В РЕАЛЬНЫХ приложениях OpenMP используется?

     
     
  • 5.40, Аноним (-), 21:44, 13/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> В РЕАЛЬНЫХ приложениях OpenMP используется?

    ImageMagick только))

     

  • 1.4, YetAnotherOnanym (ok), 20:02, 11/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Позитивно :)
    Странно только, что такое положение дел так долго терпели.
     
  • 1.5, nuclearcat (?), 20:12, 11/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Кхм, в Линуксе per-cpu counters уже черт знает сколько существуют. Фря конечно впереди планеты всей.
     
     
  • 2.9, Аноним (-), 21:24, 11/04/2013 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > впереди планеты всей.

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

     
     
  • 3.13, iZEN (ok), 22:15, 11/04/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> впереди планеты всей.
    > Да они такие инноваторы что даже апач с яхой заманались. Хотя этих
    > древних зубров вообще сложно на что либо сподвигнуть - они толстокожие
    > неимоверно.

    В каком году, ась? Не в тех ли годах, когда началась массовая истерия олинуксячивания всех и вся? Начиная, примерно, с 2003-2006 годах, когда Linux после неоднократных миллионных вливаний IBM был наконец-то готов к продакшену с классической журналируемой Ext3 (ага — после двух или трёх лет внедрения журнала в Ext2), а FreeBSD с экспериментальной поддержкой SMP в ULE и, опять же, экспериментальной UFS2, созданной на университетские гранты, была ещё не готова к распределённым нагрузкам?

     
     
  • 4.25, Аноним (-), 08:57, 12/04/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > ULE и, опять же, экспериментальной UFS2, созданной на университетские гранты,

    Этот ваш экспериментальный UFS2 на самом деле экскрементальный. Создан из окаменелых экскрементов мамонта - древнючего UFS. И капитально его переделывать никто не стал - бздоиды как обычно заявили что "на это нет ресурсов". Так что нехай будет вот таким вот уродцем внутрях. Кроме всего прочего по этой причине у него отстойная производительность на многих ворклоадах. Почему-то как ни бенч фороникса с UFS2, так грохот кирпичей бздоидов слышен за километры.

     
     
  • 5.34, iZEN (ok), 14:44, 12/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> ULE и, опять же, экспериментальной UFS2, созданной на университетские гранты,
    > Этот ваш экспериментальный UFS2 на самом деле экскрементальный. Создан из окаменелых экскрементов мамонта - древнючего UFS. И капитально его переделывать никто не стал
    > - бздоиды как обычно заявили что "на это нет ресурсов".

    "Ext2 + журналирование => Ext3 + экстенты => Ext4" — тоже историю надо знать.

    > Так что нехай будет вот таким вот уродцем внутрях. Кроме всего прочего
    > по этой причине у него отстойная производительность на многих ворклоадах.

    На каких конкретно?

    > Почему-то как ни бенч фороникса с UFS2, так грохот кирпичей бздоидов слышен за километры.

    Последний раз они тестировали быстродействие классических ФС где-то в 2010 году, если не ошибаюсь. UFS2 с SU+J в тесты не попала.


     
  • 2.35, тигар (ok), 14:44, 12/04/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    ну, это оттого, что поклонники фри, вместо того чтобы кодить, выискивают в Сети код, который называют говном. а после чего срутся на 100+ форумных веток с обиженным автором говнокода, да.;)
     

  • 1.7, fi (ok), 20:19, 11/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Я то думал, почему не растет скорость tcp при увеличении процессоров.
    бздишникам  подарили много процессорную тачку? :)
     
  • 1.10, Аноним (-), 21:36, 11/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    =====
    ping svn0.us-west.FreeBSD.org
    ping svn0.us-east.FreeBSD.org
    ======
    svn co http://svn0.us-east.FreeBSD.org/base/head /usr/src
    или
    svn co http://ping svn0.us-west.FreeBSD.org/base/head /usr/src

    =====

    http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/svn-mirrors.html

     
  • 1.15, Аноним (-), 23:59, 11/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Никто случаем не знает, что за тулза использовалась в исходном письма для вывода статистики? Тоже такую хочу.
     
     
  • 2.31, BayaN (ok), 13:25, 12/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Если ты про это письмо http://lists.freebsd.org/pipermail/freebsd-arch/2013-April/014228.html

    То это ministat(1) - http://svnweb.freebsd.org/base/head/usr.bin/ministat/
    Ну и в репах Debian я её точно видел.

     

  • 1.20, Аноним (-), 01:53, 12/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    и как задействовать это в ядре ?
    sysctl ?
     
     
  • 2.32, BayaN (ok), 13:38, 12/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это внутренний фреймворк ядра, задействовать его должны разработчики. Глеб вот переводит сетевой стек на его использование.
     

  • 1.36, deadless (ok), 17:34, 12/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    жаль что опеннет всетаки превратился в клоаку по образу и подобию лора. переименовать в линукснет и оставить их тут с Богом, с риторикой убунту вс генту... детский сад, ясельная группа..
     
     
  • 2.41, Аноним (-), 21:30, 14/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Как говорится, "каков поп, таков и приход"
     

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



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

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