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

Ответ на: комментарий от true_admin 22.01.13 19:45:24 MSK

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

post-factum ★★★★★
(22.01.13 21:44:52 MSK)

Ответ на: комментарий от post-factum 22.01.13 21:44:52 MSK

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

true_admin ★★★★★
(22.01.13 21:53:04 MSK)

Ответ на: комментарий от true_admin 22.01.13 20:54:25 MSK

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

wrong

mv ★★★★★
(22.01.13 21:56:00 MSK)

Ответ на: комментарий от post-factum 22.01.13 21:44:52 MSK

да, даже в коде вижу где 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;  // если таск на этом ядре не исполняется то мы его не шедулим (не запихиваем в очередь на исполнение на этом проце)
...

true_admin ★★★★★
(22.01.13 21:58:08 MSK)

Ссылка

Ответ на: комментарий от mv 22.01.13 21:56:00 MSK

wrong

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

true_admin ★★★★★
(22.01.13 21:59:18 MSK)

Ответ на: комментарий от true_admin 22.01.13 21:59:18 MSK

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

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

mv ★★★★★
(22.01.13 22:01:06 MSK)

Ответ на: комментарий от mv 22.01.13 22:01:06 MSK

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

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

true_admin ★★★★★
(22.01.13 22:12:54 MSK)

Ответ на: комментарий от true_admin 22.01.13 21:53:04 MSK

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

taskset -c 0,1 ./npt

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

post-factum ★★★★★
(22.01.13 22:13:38 MSK)

Ссылка

Ответ на: комментарий от true_admin 22.01.13 22:12:54 MSK

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

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

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

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

mv ★★★★★
(22.01.13 22:18:11 MSK)

Ответ на: комментарий от mv 22.01.13 22:18:11 MSK

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

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

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

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

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

true_admin ★★★★★
(22.01.13 22:34:06 MSK)

Ответ на: комментарий от tailgunner 22.01.13 19:40:56 MSK

++

Boy_from_Jungle ★★★★
(22.01.13 22:37:50 MSK)

Ответ на: комментарий от Boy_from_Jungle 22.01.13 22:37:50 MSK

++

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

true_admin ★★★★★
(22.01.13 22:39:44 MSK)

Ответ на: комментарий от true_admin 22.01.13 22:34:06 MSK

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

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

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

ке-ке-ке

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

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

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

mv ★★★★★
(22.01.13 22:45:49 MSK)

Ответ на: комментарий от mv 22.01.13 22:45:49 MSK

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

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

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

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

true_admin ★★★★★
(22.01.13 22:52:18 MSK)

Ответ на: комментарий от true_admin 22.01.13 22:52:18 MSK

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

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

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

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

mv ★★★★★
(22.01.13 23:05:15 MSK)
Последнее исправление: mv 22.01.13 23:07:18 MSK (всего исправлений: 1)

Ответ на: комментарий от mv 22.01.13 23:05:15 MSK

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

post-factum ★★★★★
(22.01.13 23:09:50 MSK)

Ответ на: комментарий от post-factum 22.01.13 23:09:50 MSK

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

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

mv ★★★★★
(22.01.13 23:11:12 MSK)

Ссылка

Ответ на: комментарий от mv 22.01.13 23:05:15 MSK

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

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

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

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

true_admin ★★★★★
(22.01.13 23:11:53 MSK)

Ответ на: комментарий от true_admin 22.01.13 23:11:53 MSK

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

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

mv ★★★★★
(22.01.13 23:16:33 MSK)

Ответ на: комментарий от mv 22.01.13 23:16:33 MSK

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

true_admin ★★★★★
(22.01.13 23:22:10 MSK)

Ссылка

Ответ на: комментарий от true_admin 22.01.13 22:39:44 MSK

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

Boy_from_Jungle ★★★★
(23.01.13 08:47:06 MSK)

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

anonymous
(23.01.13 09:23:28 MSK)

Ссылка

Ответ на: комментарий от Boy_from_Jungle 23.01.13 08:47:06 MSK

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

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

true_admin ★★★★★
(23.01.13 15:21:14 MSK)

Ответ на: комментарий от true_admin 22.01.13 16:44:13 MSK

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

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

snizovtsev ★★★★★
(23.01.13 20:35:36 MSK)

Ответ на: комментарий от snizovtsev 23.01.13 20:35:36 MSK

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

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

true_admin ★★★★★
(23.01.13 20:39:55 MSK)

Ссылка

Ответ на: комментарий от true_admin 23.01.13 15:21:14 MSK

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

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

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

Boy_from_Jungle ★★★★
(23.01.13 23:50:03 MSK)

Ответ на: комментарий от Boy_from_Jungle 23.01.13 23:50:03 MSK

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

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

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

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

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

true_admin ★★★★★
(24.01.13 00:12:20 MSK)

Ссылка

Похожие темы