linux-kernel - Re: Real-time scheduling policies and hyper-threading

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <968281398370612@web21g.yandex.ru>
Date:	Fri, 25 Apr 2014 00:16:52 +0400
From:	Kirill Tkhai <tkhai@...dex.ru>
To:	Peter Zijlstra <peterz@...radead.org>,
	Roman Gushchin <klamm@...dex-team.ru>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	Artyom Tarasenko <atar4qemu@...il.com>
Subject: Re: Real-time scheduling policies and hyper-threading

24.04.2014, 22:59, "Peter Zijlstra" <peterz@...radead.org>:

[snip]

>>  Does anyone use rt-scheduler for runtime-like cpu-bound tasks?
>
> So in general cpu bound tasks in the RT classes (FIFO/RR/DEADLINE) are
> bad and can make the system go funny.
>
> For general system health it is important that various system tasks
> (kthreads usually) can run. Many of these kthreads run at !rt prios, and
> by having cpu bound tasks in rt prios they don't get to run.

One more word to this. I had such expirience on 2.6.33 kernel with RT patch
and weak hardware (sparc32).

Networking was actively used and application did not use any IO operations.

User needs to set all RT priorities by himself. It's necessary to set RT
priorities at least for softirqs and rcus. RT bandwidth must be switched
off.

The most giving optimization, which I receive, was after rejection from NAPI
for network adapters and splitting interrupt handler on hard and threadparts.
In this case game with binding for everything strongly improves the picture
for single problem.

Kirill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/