|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Davydov 2:5020/400 09 Apr 2005 13:28:50
To : Valentin Nechayev
Subject : Re: DragonFlyBSD
--------------------------------------------------------------------------------
> From: Valentin Nechayev <netch@segfault.kiev.ua>
> Date: Fri, 8 Apr 2005 22:59:45 +0000 (UTC)
>
>Это простой вариант, он и будет работать без особого насилия. А теперь
>представь себе драйвер UFS написанный в среде где не разрешено никаких
>вызовов с возможностью ожидания (даже для того чтобы выделить кусок памяти!)
>Hадо выделить память, прочитать блок, записать блок - заказываешь операцию,
>цепляешь callback hook на её завершение и в этом хуке разбираешься что
>получилось и заказываешь следующие действия.
Объясни мне, серому, зачем в драйвере файлухи выделять память?
>С одной стороны - масштабирование про процессорам идеальное - каждому только
>и дела что выдернуть из очереди очередное сообщение и запустить обработку.
>С другой стороны, писать под такую среду - повеситься можно.
А чё, написать враппер, который, значит, эмулирует традиционный
блокирующийся интерфейс, а сам в это время спит под шедулером. Мало,
что ли, в юзерланде врапперов?
>И без локов-то всё равно не деться - на один и тот же раздел две операции
>так просто не закажешь на двух процессорах - значит, есть где-то lock manager
Почему это? ATA кабелю абсолютно всё равно, какой из процессоров инициировал
очередную проходящую по нему команду. Так что дело тут не в разделах, а в
более высоких уровнях абстракции. А там в любом случае всякие flock(2)
придётся реализовывать.
>В общем, чего-то Диллон не договаривает. Я всё больше подозреваю, что
>преимущество стрекозла только в одном - что те самые горизонтальные
>переключения контекстов процессов, которые неизбежны в мьютексной скользящей
>схеме типа FreeBSD5, крайне дороги и диллоновые LWKT выигрывают за счёт
>одного-единственного фактора - дешевизны их переключения. В принципе она
>понятна - если ядерный процесс (тред, неважно) несёт на себе только контекст
>ядра, переключение на другой такой же будет значительно дешевле переключения
>между двумя процессами с userland'ами, контекстами FPU, MMX, SSE и прочими
>двухпудовыми гирями. Hо какова будет цена отрыва ядерных веток, работающих
>с данными пользовательских процессов, от этих процессов?
А разве всякие MMXы в ядре не используются? Hу, там, конрольные суммы
ip-пакетов считать, ещё что-нибудь в том же духе...
Вал. Дав.
--- ifmail v.2.15dev5.3
* Origin: St. Petersburg State University (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
