Re: High Resolution Timer DOS

[Ingo Molnar]

* matthieu castet <castet.matthieu@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/