* matthieu castet <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
