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