The OpenNET Project / Index page

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

В OpenBSD появились поддержка CPU affinity

23.03.2009 19:02

Для OpenBSD реализована возможность явного указания какой процесс (или, точнее, поток выполнения) на каком процессоре должен выполняться. Данный код не войдёт в уже ушедший на печать релиз OpenBSD 4.5, официальный выход которого намечен на 1 мая этого года. Зато сей затрагивающий весьма тонкие моменты в ядре код пройдёт проверку в течение полугода до создания и заморозки ветки OpenBSD 4.6.

Исторически проект OpenBSD не гнался за повышением производительности, концентрируясь на создании именно надёжной системы. Тем не менее уже много лет поддержка многопроцессорности (и, соответственно, многоядерности) имеется для практически всех поддерживающих её платформ (i386, amd64, sparc64, mvme88k).

  1. Главная ссылка к новости (http://marc.info/?l=openbsd-cv...)
Автор новости: Вадим Жуков
Тип: К сведению
Ключевые слова: openbsd, cpu, smp
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (8) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, ixrws (?), 20:51, 23/03/2009 [ответить]  
  • +/
    Ну вообще-то это боком относится к производительности или вообще к ней не относится проще говоря. А то что проект развивается не только с точки зрения полупаронидальной "семть раз отмерь", но и развивается в общем, это прекрасно. Пожалуй один из немногих проектов, разработчики которого делают свою работу молча и хорошо, за что им низкий поклон. Будь они такие же выпендрёжники как и прочие, могли бы на заборе писать - секурность, секурность и секурность и секурность подражая балмеру, а так нет, работают и знают своё дело. Пожалуй почти уже вымирающий вид:)
     
     
  • 2.2, PereresusNeVlezaetBuggy (ok), 21:03, 23/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Очень даже относится: каждое переключение процесса приводит с сбросу кэшей процессора, и если процессы распределить про (пардон) процессорам, то можно выиграть в случае словарных операций (первое пришедший в голову пример — кодирование-декодирование данных) довольно заметно.

    Главный ступор производительности (впрочем, тоже не слишком сильный) в OpenBSD сейчас — то, что ядро в любом случае выполняется только на одном процессоре. Но тут изменений в ближайшее время ждать не стоит, объём работы, которую необходимо проделать, AFAIK, слишком велик — уж лучше заняться чем-то ещё. Хотя если люди начнут активнее помогать проекту, что-нибудь наверняка изменится. ;) Только что, например, Owain Ainsworth, работющими над такими частями ОС, как поддержка DRI/DRM, кэш файловой системы, NFS, обработка прерываний и так далее, потребовалась[*] пара DVI+VGA мониторов для исправления проблем с многомониторными конфигурациями драйверов для Radeon: если кто-нибудь из местных завсегдатаев в ближайшее время собирается в Англию, может, получится собрать и передать посылочку? ;)

    * http://marc.info/?l=openbsd-misc&m=123782840024567&w=2

     
     
  • 3.4, ixrws (?), 21:36, 23/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Очень даже относится: каждое переключение процесса приводит с сбросу кэшей процессора, и
    >если процессы распределить про (пардон) процессорам, то можно выиграть в случае
    >словарных операций (первое пришедший в голову пример — кодирование-декодирование данных) довольно
    >заметно.

    Пардон, об этом даже не подумал, конечно:) Спасибо что разъяснили.
    Это кстати ещё проблема если энергосберегающий режим и ядра отключаются, тогда что называется - кранты энергосбережению:)


     
     
  • 4.6, Andrew Kolchoogin (?), 10:26, 24/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Что касается энергосбережения, то тут вообще дело не такое простое: внутри ядра Юниксов есть переменная, обновляемая по системному таймеру. Соответственно, даже если все процессы будут в состоянии "sleep", ядро все равно будет жрать энергию на изменение этой переменной.
    Сейчас Солярисники решили сделать ядро полностью асинхронным, т.е. похоронить lbolt и lbolt64, ну не знаю, насколько быстро у них это получится.
     
     
  • 5.7, PereresusNeVlezaetBuggy (ok), 11:41, 24/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Что касается энергосбережения, то тут вообще дело не такое простое: внутри ядра
    >Юниксов есть переменная, обновляемая по системному таймеру. Соответственно, даже если все
    >процессы будут в состоянии "sleep", ядро все равно будет жрать энергию
    >на изменение этой переменной.

    Ну, если только одно из многих (по крайней мере в случае SMP нет необходимости держать по экземпляру сей переменной на CPU), то не так страшно… Опять же, таймер имеет свою точность, и в рамках времени между «тиками» процессор вполне может отдохнуть. Впрочем, тут я не сильно компетентен, так что если кто уточнит/опровергнет, — буду благодарен. :)

    >Сейчас Солярисники решили сделать ядро полностью асинхронным, т.е. похоронить lbolt и lbolt64,
    >ну не знаю, насколько быстро у них это получится.

     
  • 5.8, cvsup (ok), 09:38, 25/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Сейчас Солярисники решили сделать ядро полностью асинхронным, т.е. похоронить lbolt и lbolt64, ну не знаю, насколько быстро у них это получится.

    Не знаю посчет их тенденций, но пока что телодвижений не видно, и обе щедро используются в солярисном шедулере.
    Чего не скажешь о коде FreeBSD, вот уж где вынесли последние упоминания lbolt, еще одну частицу оригинальной BSD ;)

    SVN rev 181921 on 2008-08-20 12:20:22Z by ed

    Remove the now unused 'lbolt' variable from the kernel.

    We used to have a single wait channel inside the kernel which could be
    used by threads that just wanted to sleep for some time (the next
    second). The old TTY layer was the only piece of code that still used
    lbolt, because I already removed the use of lbolt from the NFS clients
    and the VFS syncer.

     
  • 3.5, Ivan (??), 01:34, 24/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >далее, потребовалась[*] пара DVI+VGA мониторов для исправления проблем с многомониторными конфигурациями
    >драйверов для Radeon: если кто-нибудь из местных завсегдатаев в ближайшее время
    >собирается в Англию, может, получится собрать и передать посылочку? ;)

    Не совсем без оснований полагаю что в Англии уже и жк-монитор (если не full-hd-панель (хотя, тут, может быть, и горячусь)) с DVI можно слегка обшарпаный найти на помойке (особенно университетской), не говоря уже купить за полфига на барахолке.

     
  • 2.3, Arti (??), 21:07, 23/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Миграция процесса с ядра имет свою цену. Именно поэтому однопоточные приложения часто выполняются значительно быстрее(если у него нет конкурентов), если в системе отключить все ядра процессора кроме одного.
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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