Что лучшее линукс ядро ​​механизм блокировки для конкретного сценария

Question

мне нужно решить проблему запирающей для этого сценария:

1. мульти системы CPU.
2. Все процессоры используют общий (программный) ресурс.
3. Только для чтения доступ к ресурсу очень распространен. (Обработка входящих сетевых пакетов)
4. Доступ к записи намного реже. (Довольно много изменений конфигурации).

В настоящее время я использую механизм read_lock_bh, write_lock_bh (spinlocks). Проблема в том, что чем больше процессоров, тем больше я получаю мягкие блокировки в контексте писателя.

Я прочитал главу о параллелизме в this book, Но не мог понять, будет ли читатель или писатель получать приоритет при использовании спин-блокировок.

Так вопросы:

1. не ли механизм спинлок Linux отдавать приоритет считывания/записи/ни один из них?
2. Есть ли лучший механизм, который я могу использовать, чтобы избежать этих мягких блокировок в моем сценарии, или, может быть, способ предоставить приоритет писателю всякий раз, когда он пытается получить блокировку, используя мое текущее решение?

Спасибо, Nir

Answer 1

Вот прямая цитата из Essential Linux Device Drivers, которая может быть тем, что вы ищете. Кажется, часть, в РКО в конце может быть то, что вы заинтересованы в.

Считыватель-Writer Замки

Другой специализированный механизм регулирования параллелизм читатель-писатель вариант спин-блокировок. Если использование критического раздела таково, что отдельные потоки либо читаются, либо записываются в общую структуру данных, но не делают оба эти замка являются естественными. Одновременно допускаются несколько потоков считывателей внутри критической области. Читатель спин-блокировки, определяются следующим образом:

rwlock_t myrwlock = RW_LOCK_UNLOCKED; 

read_lock(&myrwlock);    /* Acquire reader lock */ 
/* ... Critical Region ... */ 
read_unlock(&myrwlock);   /* Release lock */ 

Однако, если автор поток входит в критическую секцию, другой читатель или пишущий нити не допускаются внутрь. Чтобы использовать писатель спин-блокировки, можно было бы написать так:

rwlock_t myrwlock = RW_LOCK_UNLOCKED; 

write_lock(&myrwlock);   /* Acquire writer lock */ 
/* ... Critical Region ... */ 
write_unlock(&myrwlock); /* Release lock */ 

Посмотрите на код маршрутизации IPX в настоящее время net/ipx/ipx_route.c для реальной жизни примера читатель-писатель спин-блокировки. A блокировка чтения-записи под названием ipx_routes_lock защищает таблицу маршрутизации IPX от одновременного доступа.Темы , которым необходимо искать таблицу маршрутизации для пересылки пакетов, запрашивающих блокировки чтения. Темы, которые необходимо добавить или удалять записи из таблицы маршрутизации, приобретают блокировки писателя. Это улучшает производительность, потому что обычно есть гораздо больше экземпляров поиска в таблице маршрутизации, чем обновления таблицы маршрутизации.

Как регулярные спин-блокировок, читатель-писатель замки также имеют соответствующие IRQ варианты, а именно, read_lock_irqsave(), read_lock_irqrestore(), write_lock_irqsave() и write_lock_irqrestore(). Семантика этих функций аналогична функциям регулярных спин-блокировок.

Последовательные блокировки или seqlocks, введенные в ядро ​​2.6, являются блокирами чтения-записи, где авторы предпочитают более читателей. Это полезно, если операции записи в переменной, доступной только для чтения. Примером может служить переменная jiffies_64, обсуждаемая ранее в этой главе. Нити Writer не ждут читателей, которые могут находиться внутри критической секции. Из-за этого, читатель потоки могут обнаружить, что их запись в критической секции не удалось и, возможно, придется повторить:

u64 get_jiffies_64(void) /* Defined in kernel/time.c */ 
{ 
    unsigned long seq; 
    u64 ret; 
    do { 
     seq = read_seqbegin(&xtime_lock); 
     ret = jiffies_64; 
    } while (read_seqretry(&xtime_lock, seq)); 
    return ret; 
} 

Писатели защиты критических областей с помощью write_seqlock() и write_sequnlock().

ядра 2.6 введен другой механизм, называемый Read-Copy Update (РКО), , которая дает улучшился производительности, когда читатели гораздо больше, чем писатели. Основная идея заключается в том, что потоки считывателя могут выполняться без блокировки . Потоки писателей более сложны. Они выполняют операции обновления на копии структуры данных, а заменяют указатель, который видят читатели. Исходная копия сохраняется до следующего коммутатора контекста на всех процессорах до , что обеспечивает завершение всех текущих операций чтения. Имейте в виду, что использование RCU более активно, чем использование примитивов , обсуждаемых до сих пор, и их следует использовать, только если вы уверены, что это правильный инструмент для работы. Данные RCU Структуры и интерфейсные функции определены в include/linux/rcupdate.h. Существует достаточная документация в Documentation/RCU/*.

Для примера использования RCU, посмотрите на fs/dcache.c. В Linux каждый файл связан с записью каталога (хранится в структуре под названием dentry), информацией метаданных (хранимой в inode) и фактическими данными (хранится в блоках данных). Каждый раз, когда вы работаете с файлом, обрабатываются компоненты в пути к файлу, и получается соответствующих зубных рядов. Штифты хранятся в кэше в структуре данных, называемой dcache, до ускоряют будущие операции. В любое время количество запросов dcache намного больше, чем обновление dcache, поэтому ссылки на dcache защищены с помощью примитивов RCU.

Answer 2

Если работа, которую вы делаете, удерживая блокировку мала, вы можете попробовать обычный семафор, номер читатель-писатель. Это более эффективно.

Answer 3

Разве это не тот случай использования RCU, который предназначен для обработки? См. http://lwn.net/Articles/262464/ для хорошей записи на его использование.