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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ