[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20070429164230.GA23337@elte.hu>
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/
Powered by blists - more mailing lists