linux-kernel - 1 RT task blocks 4-core machine ?

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-next>] [day] [month] [year] [list]

Message-ID: <4CAA54A1.6050507@sssup.it>
Date:	Tue, 05 Oct 2010 00:26:41 +0200
From:	Tommaso Cucinotta <tommaso.cucinotta@...up.it>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Dhaval Giani <dhaval.giani@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Dario Faggioli <faggioli@...dalf.sssup.it>,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	linux-kernel@...r.kernel.org
Subject: 1 RT task blocks 4-core machine ?

Hi,

I noticed that I can loose control of a 2.6.35 kernel running on a 
4-core system in a way which I find quite unexpected:

   chrt -r 1 /usr/bin/yes > /dev/null

(default 95% per-cpu throttling). Ok, with rt bandwidth migration
among cores, my yes process will take undisturbed 100% of *one* core,
but I would be supposed to keep controlling the system using the
other three ones, wouldn't I ?

Instead, If I'm from a terminal, then I loose control of it, console
switching does not work anymore. Apparently I cannot do anything, but
sometimes I can log via ssh from another system.
A similar behavior happens if I try from ssh or from X.

Sometimes, my key presses (e.g., Alt-F2) are followed many many second
later. Except Alt-Sys-rq, which keep working, unless I come up with the
very bad idea of trying to "Nice all RT Tasks". This causes a real
freeze.

A possible explanation might be that the CFS load balancing logic sees
my only active task (e.g., the ssh server or shell etc.) as running
alone on its core, and does not detect that it is inhibited to actually
run due to RT tasks on the same core. Therefore, it will not migrate
the task to the free cores. Does this explanation make sense
or is it completely wrong ?

Also, I'd like to hear whether this is considered the "normal/desired"
behavior of intermixing RT and non-RT tasks.

Thanks and regards,

	Tommaso
-- 
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://retis.sssup.it/people/tommaso
--
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/