LINUX.ORG.RU

отдать ядро процессора под управление конкретного потока

 


1

5

Представим ситуацию — есть поток, тело которого обязано выполняться с высокой частотой (ВЧ поток). И есть параллельный код, естественно крутящийся в других потоках, который, разрастаясь, возможно в будущем начнет ломать тайминги ВЧ потока.

  1. Можно ли как-то указать планировщику, чтобы тот на определенном ядре процессора разрешал крутиться только конкретному потоку/набору потоков?
  2. Достаточно ли выставить высокий приоритет ВЧ? А если параллельно обеспечить дикую загрузку ЦП путем большого количества потоков среднего приоритета, то что будет с ВЧ потоком?

RT-ядро здесь так-то наверное самое резонное решение, но возиться с его прикручиванием совсем не хочу (и пока не сильно нужно).


Ответ на: комментарий от Dennis7

во, интересная штука... надо бы для нее тесты нарисовать. благодарю))

Burns ()
Ответ на: pthread_setschedparam от ussr

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

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

Burns ()
Ответ на: комментарий от Burns

Но на данном процессоре будет не только ваш поток или нет? Т.е. кроме того что вы выделете под него отдельный процессор кроме того наверное необходимо и объяснить что его не нужно вытяснять или я что то не понял?

ussr ()
Ответ на: комментарий от ussr

Для этого можно выставить affinity и остальным процессам. Проще всего отнять у всех остальных процессов любое/все ядра, кроме нулевого, через параметр ядра isolcpus=

anonymous ()
Ответ на: комментарий от anonymous

affinity для остальных процессов звучит интересно. Т.е необходимо перечислить и отследить все fork и pthread? А если они создаются динамически? Я предлагаю использовать управление планировщиком для реализации RT. Кроме того будет возможность использовать ядро если нужная нить спит...

ussr ()
Ответ на: комментарий от ussr

необходимо перечислить и отследить все fork и pthread? А если они создаются динамически

Просто прописываешь параметр ядра isolcpus=1-3, и больше ничего делать не нужно.

anonymous ()
Ответ на: комментарий от ussr

я выделяю не отдельный процессор, а ядро процессора. Тут лучше бы не путать терминологию. Важно то, что в определенные промежутки времени софтинушка моя, возможно, займет 100% процессорного времени, что нарушит правильность ВЧ потока. Кроме этой софтинушки на железе крутится только ядро линукса, так что при распределении потоков по ядрам процессора накладные расходы ядра линукса в теории нарушить работу ВЧ потока не должны.

Burns ()
Ответ на: комментарий от Burns

Для этого я и предлагаю изменить приоритет процесса и изменить планировщик, т.к. как только Вашему более приоритетному потоку ВЧ потребуется поработать ему ядро передаст управление.Т.е. можно совместить выделение под вашу задачу отдельного ядра для балансировки и изменения подхода к планированию планировщика Linux.

ussr ()
Ответ на: комментарий от Burns

Накладные расходы ядра linux это какие? Насколько тогда критично время отклика для ВЧ? Сколько выполняется ВЧ, а сколько спит? Сколько у Вас ядер, если можно отдать одно под отдельную задачу?

ussr ()
Ответ на: комментарий от ussr

cgroups тоже умеет привязывать всю группу к конкретному cpu

vzzo ★★★ ()

Полностью изолировать процесс на выделенном ядре без гипервизора не получится

возможно в будущем начнет ломать тайминги ВЧ потока

это вот говорит о том что какое-то фуфло затевается - тайминги твои без RT патча сломаться могут в любой момент из-за любого кривого драйвера

anonymous ()
Ответ на: комментарий от anonymous

плюсую анонима, ощущение что тс подыскивает костылек под свое поделие

и да упомянутые здесь аффинити и цпусеты вылезли вовсе не из рт задач, а из нумы, и к тому же лет так несколько назад установленное аффинити «ломалось» если дернуть цпу хотплаг, думаю что и сейчас ничего не изменилось

anonymous ()
Ответ на: комментарий от ussr

Накладные расходы ядра linux это какие?

с ядром знаком поскольку постольку. Предположительно это прерывания процессора, планировщик потоков/процессов, менеджер памяти

Сколько выполняется ВЧ, а сколько спит?

Частота 500 Гц. Занимает примерно 30% периода.

Насколько тогда критично время отклика для ВЧ?

Не допускается потеря ни одного такта

Сколько у Вас ядер?

core i7 (1 проц, 4 физических, 8 логических)

Burns ()
Ответ на: комментарий от Burns

Частота 500 Гц. Занимает примерно 30% периода.
core i7 (1 проц, 4 физических, 8 логических)

если нужен Linux - ставь ядро с RT-патчем и все будет OK без всякой ерунды с выделенным процессором которую ты напридумывал

Не допускается потеря ни одного такта

это вообще нереализуемо в многозадачной многопроцессороной системе с кешами

anonymous ()
Ответ на: комментарий от anonymous

тайминги твои без RT патча сломаться могут в любой момент из-за любого кривого драйвера

снова почитал про принцип работы RT ядра. Все-таки стоит с ним познакомиться, выглядит действительно наиболее подходящим решением.

Burns ()
Ответ на: комментарий от Burns

Частота 500 Гц. Занимает примерно 30% периода. Не допускается потеря ни одного такта. core i7 (1 проц, 4 физических, 8 логических)

Вообще не проблема. Даже не надо привязывать к ядру процессора. Достаточно просто выставить приоритет реального времени.

Привязка к ядру процессора применяется тогда, когда нужна быстрая реакция - в пределах миллисекунды.

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

Рассмотрите лучше использование микроконтроллера, например, STM32.

Deleted ()
Ответ на: комментарий от Deleted

Вообще не проблема. Даже не надо привязывать к ядру процессора. Достаточно просто выставить приоритет реального времени.

Почему-то я не доверяю моментам, когда проц может просесть в 100% загрузку.

А вообще использовать комп общего назначения для системы реального времени - плохая затея
Рассмотрите лучше использование микроконтроллера

Безусловно Вы правы, однако есть некие сложности, в основном связанные со сроками и не совсем правильным взаимодействием. Поэтому приходится тыкать дерьмо палкой

Burns ()
Ответ на: pthread_setschedparam от ussr

Вот я очередной раз попробовал изменить приоритет и параметр потока (50/SCHED_FIFO) и в очередной раз эта фича меня огорчила.

Параллельно встала более интересная задача - есть два потока, в каждом из них висит udp.receive(), который принимает пакеты с частотой 25 000 Гц.

Для того, чтобы не было потерь, выставлены опции буфера сокета на 4МБ - вполне хватает за глаза, но!

нарисовал cpu_loader с регулировкой нагрузки ядер проца, чтобы смотреть на потери. Тело нагрузки примитивное

void load_function()
{
    std::cout << "Thread started\n";
    volatile double k = 10;
    volatile double j = 0.33;
    volatile double R = 1.0;
    while (isRun)
    {
        for(int i = 0; i <  1*1000*1000; ++i)
        {
            R = k / j;
        }
        std::this_thread::sleep_for(std::chrono::milliseconds(load_delay_msec));
    }
    std::cout << "Thread finished\n";
}

нагрузку смотрю с помощью htop. В результате получил, что в промежутке с 50% до 70% загрузки ядер идут потери udp пакетов (большими пачками, возможно как раз этими 4МБ). Причем выставление приоритетов никак не повлияло на работу. Я тут как бы не понимаю, почему при 60% начинаются пропуски, а при 100% загрузке все ок? Какая-то хрень честно говоря

Burns ()
Ответ на: комментарий от ussr

Можно еще попробывать использовать SCHED_DEADLINE

Можно. Довольно полноценная интересная презентация. Как-нибудь нужно будет разобрать по полкам все что в ней написано)) Благодарю!

Burns ()
Ответ на: комментарий от Burns

Посмотрите pthread_getschedparam в этих патоках. М.б. set не отработал?

ussr ()
Ответ на: комментарий от Burns

cat /boot/config-3.13.0-24-generic | grep IOSCHED или dmesg | grep scheduler что выдает?

ussr ()
Ответ на: комментарий от ussr

М.б. set не отработал?

Это в первую очередь проверил. Все отработало

cat /boot/config-3.13.0-24-generic | grep IOSCHED или dmesg | grep scheduler что выдает?

На работе дефолтная ubuntu 14.04.1 стоит. Должно быть все в стоке. Единственное что - пришлось настроить сокеты в системе, чтобы можно было буферы для сокетов большие выставлять по данной статье. Все, более ничего не менялось

Burns ()
Ответ на: комментарий от Burns

Как реализован опрос каждые 40 микросекунд? Если через nanosleep, то как мне кажется он не дает такого разрешения кажется 1 или 10 миллисекунд.

ussr ()
Ответ на: комментарий от Burns

Я бы предложил вам открыть новую ветку, возможно будет больше участников т.к. данная ветка закрыта. Вопрос в том как вы делаете опрос 25 КГц насколько я понял в пространстве пользователя, т.е. вы в бесконечном цикле опрашиваете флаг или спите на дескрипторе(например ждете GPIO) или еще как? Опишите алгоритм работы. Используете ли неблокирующую работу с сокетами? Непонятно как связано чтение из сокетов в разных потоках и частота 25 КГц?

ussr ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.