|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 09 Apr 2005 02:59:45
To : Lev Serebryakov
Subject : Re: DragonFlyBSD
--------------------------------------------------------------------------------
>>> Lev Serebryakov wrote:
VN>> будет лежать. И если мьютексная (неважно, с квадратно-гнездовой
VN>> сериализацией, как в Linux, или скользящей, как во FreeBSD5) понятна
LS> Что подразумевается под этими терминами?
Термины мои личные, общепринятых не знаю.
Линуксовая сериализация в значительно большей мере построена на одном базовом
приёме - одновременно за счёт запрета прерываний не допускается вмешательство
обработчика на своём процессоре, а за счёт спинлока - любого кода на соседнем.
Поэтому сериализация квадратная. (Про гнездовую я уже приписал для красного
словца;))
От этой схемы постепенно начали отходить только в 2.4-не-первых и 2.5,
переложив часть работы (но не всю) на ядерные процессы; развитие же 2.0->2.4
шло по пути увода всё большей части кода от big kernel lock.
В отличие от Linux, во FreeBSD5 все прерывания (кроме таймерного, да и то
не сразу по введению SMPng) были сделаны как минимальный обработчик собственно
факта прерывания и далее побудка ядерного процесса, связанного с этим
прерыванием и работающего под шедулером; вместо IPL'ей и спинлоков были
введены семафоры с возможностью сна. С одной стороны это хорошо - например,
kernel preemption получается почти автоматически. С другой, горизонтальное
переключение (между процессами) традиционно значительно дороже, чем
вертикальное (между userland, top half, bottom half), поэтому введение SMPng
дало резкое замедление. При его введении обещали сделать какие-то "отложенные
переключения контекстов" чтобы удешевить переключения, но судя по результатам -
ничего пока не сделали.
VN>> большому числу народа, то как строить без безумного геморроя схемы на
VN>> сообщениях - знает значительно меньше грамотных людей. И тех в
VN>> основном утянули писать драйвера под NT.
LS> Hу вот у нас весь многопоточный проект на приоритетных очередях заданий
LS> (те же сообщения). Прекрасно работает. :) Локов очень мло в результате :)
Это простой вариант, он и будет работать без особого насилия. А теперь
представь себе драйвер UFS написанный в среде где не разрешено никаких
вызовов с возможностью ожидания (даже для того чтобы выделить кусок памяти!)
Hадо выделить память, прочитать блок, записать блок - заказываешь операцию,
цепляешь callback hook на её завершение и в этом хуке разбираешься что
получилось и заказываешь следующие действия.
С одной стороны - масштабирование про процессорам идеальное - каждому только
и дела что выдернуть из очереди очередное сообщение и запустить обработку.
С другой стороны, писать под такую среду - повеситься можно.
И без локов-то всё равно не деться - на один и тот же раздел две операции
так просто не закажешь на двух процессорах - значит, есть где-то lock
manager который смотрит на состав объектов над которыми действует операция,
и даёт на выполнение только то, что не дерётся с уже занятыми локами. И чем
это будет лучше традиционного для pthreads или FreeBSD5 подхода "хочешь
лок, занято - идёшь спать пока не освободят, а мы пока с кем-то ещё поработаем"?
В общем, чего-то Диллон не договаривает. Я всё больше подозреваю, что
преимущество стрекозла только в одном - что те самые горизонтальные
переключения контекстов процессов, которые неизбежны в мьютексной скользящей
схеме типа FreeBSD5, крайне дороги и диллоновые LWKT выигрывают за счёт
одного-единственного фактора - дешевизны их переключения. В принципе она
понятна - если ядерный процесс (тред, неважно) несёт на себе только контекст
ядра, переключение на другой такой же будет значительно дешевле переключения
между двумя процессами с userland'ами, контекстами FPU, MMX, SSE и прочими
двухпудовыми гирями. Hо какова будет цена отрыва ядерных веток, работающих
с данными пользовательских процессов, от этих процессов?
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
