Книга: Разработка ядра Linux
Ограничение частоты следования событий при отладке
Ограничение частоты следования событий при отладке
Часто необходимо встроить в код отладочные проверки (с соответствующими функциями вывода информации), чтобы визуально производить мониторинг проблемы. Однако, в ядре некоторые функции вызываются по много раз в секунду. Если в такую функцию будет встроен вызов функции printk()
, то системная консоль будет перегружена выводом отладочных сообщений и ее будет невозможно использовать.
Для предотвращения такой проблемы существует два сравнительно простых приема. Первый — ограничение частоты следования событий — очень полезен, когда необходимо наблюдать, как развивается событие, но частота возникновения события очень большая. Чтобы ограничить поток отладочных сообщений, эти сообщения выводятся только раз в несколько секунд, как это показано в следующем примере.
static unsigned long prev_jiffy = jiffies; /* ограничение частоты */
if (time_after(jiffies, prev_jiffy + 2*HZ)) {
prev_jiffy = jiffies;
printk(KERN_ERR "blah blah blahn");
}
В этом примере отладочные сообщения выводятся не чаще, чем один раз в две секунды. Это предотвращает перегрузку консоли сообщениями и системой можно нормально пользоваться. Частота вывода может быть большей, или меньшей, в зависимости от требований.
Вторая ситуация имеет место, когда необходимо замечать любые появления события. В отличие от предыдущего примера нет необходимости выполнять мониторинг развития событий. А только получить сообщение о том, что что-то произошло. Вероятно это уведомление необходимо получить один, или два раза. Проблема возникает в том случае, если проверка, которая после того, как сработала один раз, начинает срабатывать постоянно. Решением в данном случае будет не ограничение частоты, а ограничение общего количества повторений.
static unsigned long limit = 0;
if (limit < 5) {
limit++;
printk(KERN_ERR "blah blah blahn");
}
В этом примере количество отладочных сообщений ограничено числом пять. После пяти сообщений условие всегда будет ложно.
В обоих примерах переменные должны быть статическими (static
) и локальными по отношению к той функции, где используются. Это позволяет использовать одинаковые имена переменных в разных функциях.
Ни один из этих примеров не рассчитан на SMP, или преемптивность, хотя очень легко перейти к атомарным операциям и сделать их безопасными для использования и в этих случаях. Однако, честно говоря, это всего лишь отладочный код, поэтому зачем нужны лишние проблемы?
- Глава 5. Хроника предшествующих событий
- Раздел VII Левиафан в Сети: защита права на тайну частной жизни после событий 2013 г.
- Ограничение времени ожидания для транзакций (Lock timeout)
- Ограничение результатов выборки FIRST
- 2.2. Современные методы исследования эффективности рекламы
- Расширение механизма событий
- 3. Ограничение целостности по состоянию
- 1. Ограничение функциональной зависимости
- Смысл наследования
- 1.1.1. Исследования
- 4.11.5. Ограничение сети
- Ограничение сценариев