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

Говорю же — не работало. Надо ещё раз потестить…

значит был или баг или проблема с тулзами. Ты как выставлял аффинити? schedutils понимает числа только в heх, я сам долго гадал «отчего же ничего работает».

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

wrong

да, даже в коде вижу где affinity учитывает. Он отдельно для каждого ядра таски шедулит. И там есть такое:

static inline bool needs_other_cpu(struct task_struct *p, int cpu)
{
	if (unlikely(!cpu_isset(cpu, p->cpus_allowed)))
		return true;
	return false;
}

[...]

static inline struct
task_struct *earliest_deadline_task(struct rq *rq, int cpu, struct task_struct *idle)
{
...
			/* Make sure cpu affinity is ok */
			if (needs_other_cpu(p, cpu))
				continue;  // если таск на этом ядре не исполняется то мы его не шедулим (не запихиваем в очередь на исполнение на этом проце)
...

wrong

что wrong? Речь не о системном программировании когда надо ядро освободить, скажем, для другой ОС.

что wrong? Речь не о системном программировании когда надо ядро освободить, скажем, для другой ОС.

Да пофиг, пока workqueues на этом проце висят, ты его полностью под себя положить не сможешь, не зафакапив всей системы.

Ты живёшь в каком-то своём мире.

Проц будет на ~99% свободен, этого достаточно. Даже для многих нитей ядра можно задать affinity.

Всё, каюсь, проверил — работает.

taskset -c 0,1 ./npt

npt — такая штука, которая считает в 4 потока. Если запустить её так, как я написал выше, используются первые два проца. Замурчательно.

Ты живёшь в каком-то своём мире.

Ага, и в нём Линукс для сколь-нибудь серьёзного лоу-лейтенси рилтайма не годен.

Проц будет на ~99% свободен, этого достаточно. Даже для многих нитей ядра можно задать affinity.

Проблема не в том, что тебе 99% достаточно. Проблема в том, что если ты его займёшь под себя, не делясь с этими wq, то у тебя система работать перестанет.

Ага, и в нём Линукс для сколь-нибудь серьёзного лоу-лейтенси рилтайма не годен.

Я тебе более того скажу, x86 для этого слабо пригоден.

Проблема в том, что если ты его займёшь под себя, не делясь с этими wq, то у тебя система работать перестанет.

У ОС всегда есть на себя время потому что многозадачность вытесняемая. А ещё есть kernel.sched_latency_ns и kernel.sched_min_granularity_ns которые работают, я проверял.

Не, ну можно сдуру и йух сломать, но это уже придётся постараться.

++

++

аргументы будут? В последнем сравнении датированным концом прошлого года bfs побыстрее был. Лень искать pdf-ку, в гугле найдётся.

Я тебе более того скажу, x86 для этого слабо пригоден.

С чего бы вдруг?

У ОС всегда есть на себя время потому что многозадачность вытесняемая.

ке-ке-ке

А ещё есть kernel.sched_latency_ns и kernel.sched_min_granularity_ns которые работают, я проверял.

Это как дроческоп из Ашана: пока ездишь, как бабушка - всё ок, супер-агрегат. И выгодный. А как дроп сделал, так ещё лёжа в больнице начнёшь размышлять, что высота дропа у BMX/DH - это функция от его стоимости, фактически. Но кататься по парку на BMX/DH всё равно нифига не удобно, хотя вагон денег в него ввалил.

А так подумать - ну всё те же рама, два колеса, руль и сидушка.

С чего бы вдруг?

знакомый занимался софтварными роутерами на линухе. Как раз то что ты описывал: на одном ядре линух для менеджмента, а втором свой rt-костыль. Вот с его слов добиться аккуратности в сотни наносекунд не получалось (нужно успеть принять решение за интервал между фреймами у 1G/10G/XXG ethernet).

Это как дроческоп из Ашана

Мда, старожилы уже не те. Я так понимаю что внятного объяснения мыслей не будет. И уж тем более демонстрации проблемы. А я вот целыми днями сижу-ковыряю cgroups с performance counters и как раз занимаюсь тем чтобы соптимизировать производительность приложений в облаке. Так что ты не стесняйся, можешь сыпать сложными техническими терминами, я нагуглю. И велик у меня есть, но, если можно, давай обойдёмся без велосленга.

знакомый занимался софтварными роутерами на линухе. Как раз то что ты описывал: на одном ядре линух для менеджмента, а втором свой rt-костыль. Вот с его слов добиться аккуратности в сотни наносекунд не получалось (нужно успеть принять решение за интервал между фреймами у 1G/10G/XXG ethernet).

Дак это не хватает мощей на throughput. С 10G входом и на FPGA не особо разбежишься. А так, если всё держать локально, вражьи интеррапты раскидать, SMM позапрещать, линукс выкинуть то всё достаточно предсказуемо и быстро.

Я так понимаю что внятного объяснения мыслей не будет. И уж тем более демонстрации проблемы.

ps ax сделай, посмотри на процессы с именем типа [foo/X], погугли, что они делают, и подумай, как именно встанет раком система, если они шедуллиться не будут.

Скоростной пассивный мониторинг и на 10G можно проводить.

Скоростной пассивный мониторинг и на 10G можно проводить.

С кучей оговорок, и если только на хидеры смотреть.

ps ax сделай, посмотри на процессы с именем типа [foo/X], погугли, что они делают, и подумай, как именно встанет раком система, если они шедуллиться не будут.

Ура, пошла конкретика.

Почему это они шедулится не будут? Они ещё как будут шедулиться на тех ядрах что им можно. Для самых критичных из них стоит affinity на уровне ядра (забыл как называется) и rt-приоритет, поэтому их перебросить вообще не получится. Я поэтому и писал что полностью освободить ядро проца от всех процессов может и не получится. Мне кажется совсем запретить ядру шедулить свои потоки нельзя. Можно выставить дурацкие паретры планировщику и добиться адских лагов, у меня такое получалось, но это уже за пределами разумного.

Впрочем, я как раз эксперименты подобного рода делаю, могу даже посмотреть сколько тактов проц работает на «свободном» ядре. Что-то вроде sudo perf stat -C 1 — sleep 10 .

Почему это они шедулится не будут? Они ещё как будут шедулиться на тех ядрах что им можно.

Потому мне так надо.

ну так речь не о тебе, а о ТС. Логично что если он спрашивает как ему посадить один из потоков ОС на определённое ядро то речь не идёт о том что бы выкинуть ОС с этого ядра.

если ему пофиг на то что ему говорят делать, то зачем еще какие-то аргументы?

ставь http://article.gmane.org/gmane.linux.kernel/1413168

если ему пофиг на то что ему говорят делать, то зачем еще какие-то аргументы?

кому «ему»? Один ошибся, второй как всегда ответил в своей манере, третий поддержал не читая треда дальше. Вот так вот отличный планировщик и похоронили.

Автоматика почти всегда дурак, т.к. не знает специфики задачи. Другое дело, что вероятность дурака-человека всегда выше.

А ручное раскидывание процессов по ядрам ещё может быть актуально для realtime систем.

Автоматика почти всегда дурак, т.к. не знает специфики задачи.

Я как раз пытаюсь понять в каких случаях ручное управление тасками может помочь. Пока прихожу к выводу что в 99% лучше ничего не трогать.

кому «ему»? Один ошибся, второй как всегда ответил в своей манере, третий поддержал не читая треда дальше. Вот так вот отличный планировщик и похоронили.

OK. Если подкинешь доков по BFS буду благодарен.

З.Ы.
А вообще я не с тобой зацепиться -)
Ошибся коментом -(

Ни одно из этого не читал, так, просматривал:

http://users.on.net/~ckolivas/kernel/

http://ck.kolivas.org/patches/bfs/bfs-faq.txt

http://en.wikipedia.org/wiki/Brain_Fuck_Scheduler

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