linux-kernel - Re: High Resolution Timer DOS

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

Date:	Sun, 29 Apr 2007 18:42:30 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	matthieu castet <castet.matthieu@...e.fr>
Cc:	Lee Revell <rlrevell@...-job.com>, tglx@...utronix.de,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: High Resolution Timer DOS


* matthieu castet <castet.matthieu@...e.fr> wrote:

> Ok, may be DOS was not the correct term, [...]

ok, good that have that issue put aside ;-)

> [...] but with the 2.6.21 hrt there is a great difference between an 
> infinite loop and the high-rate context-switching task (you can try 
> attached programs). With the first I the system is still responsive, 
> with the latter it isn't (new process take lot's of time to get 
> created, other process are very slow). If it is "just 'CPU time used 
> up'", why I see a such difference between the 2 cases ?

this is a pure scheduler thing: the scheduler treats sleepers 
differently than CPU hogs. Try the same test for example under the 
(ob'plug) CFS scheduler:

   http://redhat.com/~mingo/cfs-scheduler/

and you'll see small_sleep.c being handled the same way as 
infinite_loop.c. This is a CFS box with 20 small_sleep's running:

 top - 20:41:02 up 1 min,  2 users,  load average: 4.92, 1.27, 0.43
 Tasks:  89 total,  22 running,  67 sleeping,   0 stopped,   0 zombie
 Cpu(s):  5.2%us, 46.5%sy,  1.7%ni, 17.7%id, 28.5%wa,  0.3%hi,  0.1%si,  0.0%st
 Mem:   2053204k total,   103300k used,  1949904k free,    12096k buffers
 Swap:  4096564k total,        0k used,  4096564k free,    43040k cached

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  2208 mingo     20   0  1576  256  208 R  4.5  0.0   0:01.08 small_sleep
  2252 mingo     20   0  1580  260  208 R  4.5  0.0   0:00.71 small_sleep
  2254 mingo     20   0  1576  256  208 R  4.5  0.0   0:00.61 small_sleep

and the system is still completely usable.

This isnt really about timers - you can achieve similar effects without 
using any timers.

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