Можно ли сделать 100% cpu usage в процессе с SCHED_FIFO в linux.
проблема в том что он что-то зашедулил в per-cpu workqueue что-ли?
там должен быть какой-то костыль для этого, в HPC это стандартная проблема и они всё пытаются офлоадить с процессора где идут вычисления.
возможно в ваниле этого ещё нет, тут нужно смотреть rt и прочие наркоманские проекты
там должен быть какой-то костыль для этого, в HPC это стандартная проблема и они всё пытаются офлоадить с процессора где идут вычисления.
возможно в ваниле этого ещё нет, тут нужно смотреть rt и прочие наркоманские проекты
workqueue kworker разгребает?
вообще, я посмотрел, у него
# chrt -p 23104
pid 23104's current scheduling policy: SCHED_OTHER
pid 23104's current scheduling priority: 0
Поэтому в принципе, он должен выполняться, пока я не сделаю
sched_rt_runtime_us = -1, но пока так:
ХОтя я планировал сделать sched_rt_runtime_us=-1 в общем-то.
собстенно, на ядре обнаружены следующие треды:
первые два SCHED_OTHER ( 0), вторые два SCHED_FIFO(99). Второй(ksoftirq) надеюсь, что в отсутствии прерывания на этом ядре не будет задействован (а как быть с непереносимыми прерываниями, кстати?), а вот первый погоду портит.
Какие-то способы проверить
имеются?
rt - это rtlinux ? это нужно весь проект будет переписывать. Я как-то наивно посчитал, что такая мегасложная задача, как выделить ядро под один тред и не прерывать его там решается малой кровью.
вообще, я посмотрел, у него
# chrt -p 23104
pid 23104's current scheduling policy: SCHED_OTHER
pid 23104's current scheduling priority: 0
Поэтому в принципе, он должен выполняться, пока я не сделаю
sched_rt_runtime_us = -1, но пока так:
kernel.sched_rt_period_us = 1000000
kernel.sched_rt_runtime_us = 950000
ХОтя я планировал сделать sched_rt_runtime_us=-1 в общем-то.
собстенно, на ядре обнаружены следующие треды:
29175 29175 S ? 00:00:00 [kworker/11:1]
96 96 S ? 00:00:25 [ksoftirqd/20]
97 97 S ? 00:00:35 [watchdog/20]
98 98 S ? 00:00:00 [migration/21]
первые два SCHED_OTHER ( 0), вторые два SCHED_FIFO(99). Второй(ksoftirq) надеюсь, что в отсутствии прерывания на этом ядре не будет задействован (а как быть с непереносимыми прерываниями, кстати?), а вот первый погоду портит.
Какие-то способы проверить
проблема в том что он что-то зашедулил в per-cpu workqueue что-ли?
имеются?
rt - это rtlinux ? это нужно весь проект будет переписывать. Я как-то наивно посчитал, что такая мегасложная задача, как выделить ядро под один тред и не прерывать его там решается малой кровью.
Да, kworker, их там много разных. Я не специалист по HPC так что тебе лучше пойти поискать материалы как это настраивать и использовать. Ванильное ядро сходу не готово обслуживать такой RT busy loop, дэдлоки гарантируются. Насколько я помню по дефолту RT классы ограничены и не должны занимать весь процессор полностью именно из-за этих проблем.
Что-то рытьё интернетов ничего не даёт, Может ключевые слова какие-то есть ещё, сленг какой-нибудь?
сейчас пробую разные конфигурации ядра, потм буду искать счастья на stackoverflow и может других каких форумах
сейчас пробую разные конфигурации ядра, потм буду искать счастья на stackoverflow и может других каких форумах
не думаю что ты что-то найдёшь на stackoverflow.
какие-то кривые workqueue добавили в последнем ядре чтоб не будить лишний раз спящие процессоры, как обычно power management тесно переплетается с HPC.
ещё tilera делала в своей системе ядра выделенные для юзерспейса, а сисколы исполняются в другом месте. не помню как они это называли.
какие-то кривые workqueue добавили в последнем ядре чтоб не будить лишний раз спящие процессоры, как обычно power management тесно переплетается с HPC.
ещё tilera делала в своей системе ядра выделенные для юзерспейса, а сисколы исполняются в другом месте. не помню как они это называли.
Оставить комментарий
Phoenix
По мотивам http://lkml.indiana.edu/hypermail/linux/kernel/0502.2/1550.h...Хочу выделить ядро только для одного треда.
Что делает тред:
1) socket. send/recv (non block)
2) read/write shmem
Написав то, что мне нужно и запускив в SCHED_FIFO, priority=10, выставив маски на прерывания и все другие процессы( кроме всяких kworker, ksoftirq, migration...)
наткнулся на грабли (аналогичный тем, что поссылке), сделав fprintf. Как я понимаю, этот fprintf пишет в кэш, потом запускается kernel thread, чтобы разгрести очередь, консоль залипает.
конечно, в бою ничего в консоль напрямую я выводить не планирую, но является ли данная архитектура вообще рабочей? не прилитит ли на ядро какая-нибудь хитрая задача, после чего будет вечно ожидать миграции на другое ядро, даже если я пропишу всем процессам привязку к ядрам?