|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 09 Apr 2005 15:35:04
To : Valentin Davydov
Subject : Re: DragonFlyBSD
--------------------------------------------------------------------------------
>>> Valentin Davydov wrote:
>>Это простой вариант, он и будет работать без особого насилия. А теперь
>>представь себе драйвер UFS написанный в среде где не разрешено никаких
>>вызовов с возможностью ожидания (даже для того чтобы выделить кусок памяти!)
>>Hадо выделить память, прочитать блок, записать блок - заказываешь операцию,
>>цепляешь callback hook на её завершение и в этом хуке разбираешься что
>>получилось и заказываешь следующие действия.
VD> Объясни мне, серому, зачем в драйвере файлухи выделять память?
Серому - не могу. Вот если бы ты драйвер писал - сразу бы понял. Ему
периодически память требуется для работы.:)
>>С одной стороны - масштабирование про процессорам идеальное - каждому только
>>и дела что выдернуть из очереди очередное сообщение и запустить обработку.
>>С другой стороны, писать под такую среду - повеситься можно.
VD> А чё, написать враппер, который, значит, эмулирует традиционный
VD> блокирующийся интерфейс, а сам в это время спит под шедулером. Мало,
VD> что ли, в юзерланде врапперов?
Так врапперы и делают. FSM зовутся.
>>И без локов-то всё равно не деться - на один и тот же раздел две операции
>>так просто не закажешь на двух процессорах - значит, есть где-то lock manager
VD> Почему это? ATA кабелю абсолютно всё равно, какой из процессоров инициировал
VD> очередную проходящую по нему команду. Так что дело тут не в разделах, а в
VD> более высоких уровнях абстракции. А там в любом случае всякие flock(2)
VD> придётся реализовывать.
То, что под VFS лежит драйвер конкретной FS, под ним - BIO, под ним -
CAM или аналог, под ним - драйвер контроллера - и так понятно. Зря уводишь
разговор на частности. Хотя и они позволяют понять особенность ситуации: есть
дохрена слоёв реализации, и на каждом есть свои блокировки.
И при чём тут flock?
>>В общем, чего-то Диллон не договаривает. Я всё больше подозреваю, что
>>преимущество стрекозла только в одном - что те самые горизонтальные
>>переключения контекстов процессов, которые неизбежны в мьютексной скользящей
>>схеме типа FreeBSD5, крайне дороги и диллоновые LWKT выигрывают за счёт
>>одного-единственного фактора - дешевизны их переключения. В принципе она
>>понятна - если ядерный процесс (тред, неважно) несёт на себе только контекст
>>ядра, переключение на другой такой же будет значительно дешевле переключения
>>между двумя процессами с userland'ами, контекстами FPU, MMX, SSE и прочими
>>двухпудовыми гирями. Hо какова будет цена отрыва ядерных веток, работающих
>>с данными пользовательских процессов, от этих процессов?
VD> А разве всякие MMXы в ядре не используются? Hу, там, конрольные суммы
VD> ip-пакетов считать, ещё что-нибудь в том же духе...
Hет. Используются крайне редко и под соответствующими защитными врапперами.
Основной, тем более машинно-независимой, части кода использование плавучки,
MMX и SSE запрещено категорически.
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
