исполнение задач на указанном ядре

AFAIK, it's impossible.

А кроссплатформенно?

AFAIK, it's impossible.

4.2

именно это нет,
но если другие ОСИ такое позволяют, то можно написать свою обвертку

то можно написать свою обвертку

Да что там, можно вообще MyThread написать.

не нужно, уже есть -)

у меня 4 ядраю хочу, чтобы задача исполнялась на ядре №1:

#include <sched.h>
int main(int argc, char *argv[])
{
    cpu_set_t  mask;
    CPU_ZERO(&mask);
    CPU_SET(1, &mask);
    CPU_SET(4, &mask);
    int result = sched_setaffinity(0, sizeof(mask), &mask);

    QCoreApplication a(argc, argv);
    ...
    return a.exec();
}

нет неправильно.
А вообще зачем тебе такое?

правильно сделал?

man taskset

нет неправильно.

подправьте пожалуйста. и как сделать, чтобы другие процессы ОС не садились на «занятое» ядро?

А вообще зачем тебе такое?

хочу посадить на определенное ядро pcap для чтения пакетов + хочу посмотреть насколько отдельно взятый модуль программы грузит процессор.

как сделать, чтобы другие процессы ОС не садились на «занятое» ядро?

Написать свой диспетчер процессов.

уже все написано до нас -(

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

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

зачем аффтару топика такое нужно, для каких целей

Intel, например, утверждает, что это позволяет минимизировать миграцию потоков и снизить стоимость переключения контекста между процессорами.

Для всяких числодробилок может быть актуально.

как сделать, чтобы другие процессы ОС не садились на «занятое» ядро?

На свой страх и риск:

for i in /proc/[0-9]*; do taskset -a -p 0xFFFFFFFE $(echo $i | awk -F/ '{print $3}'); done

затем

taskset -a -p 0x01 pid_твоего_процесса

А не проще ли это через cgroups/cpusets сделать ? И софт переделывать не нужно.

+1 к предыдущему оратору.

cgcreate cpuset:/mycg
echo <cpunum> | sudo tee /sys/fs/cgroup/cpuset/mycg/cpuset.cpus
cgexec cpuset:/mycg <yourtask>

Вместо echo .. | tee можно использовать cgset

Написать свой диспетчер процессов.

Грузить систему с isolatecpus=X и биндить свой процесс на X руками достаточно близко.

Кагбе, диспетчер процессов — более гибкое решение, думается мне.

а, ну понял, действительно актуально

это позволяет минимизировать миграцию потоков и снизить стоимость переключения контекста между процессорами.

а ядро тоже не дурак, оно об этом знает, см. kernel.sched_migration_cost_ns и прочие параметры шедулера.

Иногда есть профит от ручного раскидования тасков, но это всё редкие случаи.

Кагбе, диспетчер процессов — более гибкое решение, думается мне.

WDYM? Почему ты думаешь, что в случае с isolcpus его нет?

а ядро тоже не дурак, оно об этом знает, см. kernel.sched_migration_cost_ns и прочие параметры шедулера.

Ядро дурак, на самом деле. Нет возможности полностью вывести ядро из системы и крутить там свой софт.

Нет возможности полностью вывести ядро из системы и крутить там свой софт.

Это почти никому не надо, оттого и не реализовано. В ядре только то что нужно многим, остальное надо допиливать самому.

Если каждый бы тащил свой код в ядро то был бы ппц.

ты ведь под полный вывод линуха с ядра? Чтобы линух его совсем не трогал.

Это почти никому не надо, оттого и не реализовано. В ядре только то что нужно многим, остальное надо допиливать самому.

Это понятно, что всем только лолкоты нужны.

Если каждый бы тащил свой код в ядро то был бы ппц.

Ты его давно смотрел? ;)

Чтобы линукс свои грязные workqueue туда не бросал и т.п.

всем только лолкоты нужны.

лолкоты

что это?

Если BFS, ему будет глубоко пофигу на все affinity.

Если BFS, ему будет глубоко пофигу на все affinity.

откуда дровишки?

Всё там есть: http://ck.kolivas.org/patches/bfs/3.0/3.7/3.7-sched-bfs-426.patch

Он сотни раз в секунду мигрирует процессы с ядра на ядро, какая уж тут привязка. Сам Кон говорил, что аффинити для BFS — штука вовсе необязательная.

Если BFS, ему будет глубоко пофигу на все affinity.

Какое говно этот ваш BFS.

Он сотни раз в секунду мигрирует процессы с ядра на ядро

я не знаю что он там делает, но то что он процессы шедулит только на те ядра которые разрешены через setaffinity факт.

Сам Кон говорил, что аффинити для BFS — штука вовсе необязательная.

она ни для одного шедулера не обязательная.

Бла-бла, не задерживайтесь, проходите мимо.

аффинити для BFS — штука вовсе необязательная.

она ни для одного шедулера не обязательная.

Кто и где это сказал?

Кто и где это сказал?

Я говорю. Это опциональная фича.

факт

Хмээ… есть пруфы? А то как-то подозрительно. Может, это в последних версиях поведение поменялось, раньше мне не удавалось такого добиться.

купи себе нормальный селерон

Кто и где это сказал?

Я говорю.

/me вздыхает облегченно

есть пруфы?

Там прямо в коде это написано, грепай по affinity.

/me вздыхает облегченно

аргументы будут?

/me вздыхает облегченно

аргументы будут?

Аргументы в пользу чего - что я почувствовал облегчение? Нет, просто поверь на слово. В пользу того, что «опциональная» аффинность - это не аффинность вообще? Думаю, это очевидно.

+1 к предыдущему оратору.

А потом все остальные процессы снять с конкретного ядра/процессора. Всё равно же без обхода всех PID'ов не обойтись?

А потом все остальные процессы снять с конкретного ядра/процессора. Всё равно же без обхода всех PID'ов не обойтись?

Не очень понял вопрос, но список всех pid в /sys/fs/cgroup/<your_group>/tasks

Если смущает что они могут там ещё нафоркаться то можешь заморозить контейнер через freezer (такая cgroup) прежде чем убивать.

или ты имел в виду перебросить на другой проц? Тогда тупо поменять список доступных процов. Это, правда, займёт немного времени (доли секунды) т.к. изменения применяются когда они следующий раз получат квант времени.

или ты имел в виду перебросить на другой проц?

ТС хотел выделить одно ядро процессора исключительно под его программу и при этом снять с этого ядра все остальные задачи.

и при этом снять с этого ядра все остальные задачи.

Всё просто, остальные задачи загнать в другую группу и указать для неё другие ядра.

systemd, вероятно, умеет всё это из коробки.