Вопросы Теги

Потоки ядра, кажется, вмешиваются в полный режим без галочки?

Вы - более обеспеченное использование или 

awk '/CK$/,/D$/' file.txt

ИЛИ

sed -n '/CK$/,/D$/p' file.txt

Если Вы настаиваете , вот является GNU grep путем

grep -oPz '(?s)(?<=\n)\N+CK\n.*?D(?=\n)' file.txt

Здесь

-P активирует perl-regexp

-z разделитель строки наборов к NUL. Это вынуждает grep рассматривать весь файл как одну одну строку

-o печать, только соответствующая

(?s) активирует PCRE_DOTALL, таким образом, . находит любую символьную или новую строку

\N соответствия что-либо кроме новой строки

.*? находит. в нежадном режиме

(?<=..) оглянуться утверждение

(?=..) предварительное утверждение

3
06.09.2019, 11:42
1 ответ

Полный бестактовый режим, который активируется, например, с помощью. nohz_full=cpux-cpuyдействительно эффективен, только если есть только одна работающая задача на каждом nohz_fullЦП:

Adaptive-ticks does not do anything unless there is only one runnable task for a given CPU, even though there are a number of other situations where the scheduling-clock tick is not needed.

(ср. Документация/таймеры/НО _HZ.txt)

Таким образом, если вы проверяете nohz_fullЦП с помощью ps, имеет смысл явно искать исполняемые задачи -, например.:

$ ps -e -L -o cpuid,pid,lwp,state,pri,rtprio,class,wchan:20,comm \
      | awk '$1 == '$mycpunr

(т.е. посмотрите на столбец состояния)

Это означает, что можно иметь некоторые дополнительные задачи на nohz_fullЦП, если они не запускаются.

Всего лишь nohz_full=, ничто не мешает ядру планировать пользовательские/ядерные потоки на выбранных процессорах. Таким образом, обычно также изолируются эти процессоры, чтобы избежать вмешательства со стороны других потоков. Например, с:

nohz_full=cpux-cpuy isolcpus=cpux-cpuy

(ср. Параметры ядра Linux)

С этими параметрами поток на изолированном nohz_fullЦП все еще может быть прерван, например. таймерами и обратными вызовами RCU.

Таким образом, если вы хотите свести к минимуму задержку вашего изолированного потока, вам необходимо отключить другие источники прерываний.

Вы можете проверить /proc/timer_listтаймеры, которые все еще активны на изолированных ЦП.

Типичными примерами таймеров, которые могут отображаться на изолированном ЦП, являются watchdog_timer_fnи таймер, связанный с исключениями проверки машины (MCE ).

Вы можете отключить эти прерывания с помощью дополнительных параметров ядра , например.:

nowatchdog mce=ignore_ce

Просмотр счетчиков /proc/interrupts— хороший способ проверить аппаратные прерывания. Другим источником прерываний являются Softirq, поэтому также необходимо проверять счетчики /proc/softirqs.

Например, чтобы свести к минимуму прерывания, связанные с RCU, на изолированных ЦП, можно разгрузить обратные вызовы RCU на потоки ядра, перенести их на не -изолированный ЦП и освободить изолированный ЦП от необходимости уведомлять поток обратного вызова, добавив ядро. опция:

rcu_nocb_poll

Этот вариант требует, чтобы rcu_nocbs=был эффективным,но nohz_full=уже подразумевает rcu_nocbs=для указанных процессоров.

Обратите внимание, что вы явно должны переместить разгруженные потоки обратного вызова RCU на вспомогательный ЦП -, явно задав сходство ЦП для этих потоков. Например, с тунцом (на ЦП 0):

# tuna -U -t 'rcu*' -c 0 -m

В документе ядра Documentation/kernel -per -CPU -kthreads.txt описаны дополнительные источники прерываний (, также известные как джиттер ОС ), и показано, как их найти с помощью запуск тестовой нагрузки с включенной трассировкой.

5
27.01.2020, 21:23

Теги

Похожие вопросы