Messages in this thread | | | Date | Fri, 18 Jul 2003 17:41:45 +0200 | From | Mike Galbraith <> | Subject | Re: [PATCH] O6int for interactivity |
| |
At 06:46 AM 7/18/2003 -0700, Davide Libenzi wrote: >On Fri, 18 Jul 2003, Mike Galbraith wrote: > > > At 03:12 PM 7/16/2003 -0700, Davide Libenzi wrote: > > > > >http://www.xmailserver.org/linux-patches/irman2.c > > > > > >and run it with different -n (number of tasks) and -b (CPU burn ms time). > > >At the same time try to build a kernel for example. Then you will realize > > >that interactivity is not the bigger problem that the scheduler has right > > >now. > > > > I added an irman2 load to contest. Con's changes 06+06.1 stomped it flat > > [1]. irman2 is modified to run for 30s at a time, but with default > parameters. > >In my case I cannot even estimate the time. It takes 8:33 ususally to do a >bzImage, and after 15 minutes I ctrl-c with only two lines printed in the >console. If you consider the ratio between the total number of lines that >a kernel build spits out, this couls have taken hours. Also, you might
Yeah, I noticed... it's a nasty little bugger.
>want also to try a low number of processes with a short burn, like the new >patch seems to do to better hit mm players. Something like: > >irman2 -n 10 -b 40
If I hadn't done the restart after 30 seconds thing, I knew it would take ages. I wanted something to see contrast, not a life sentence ;-)
>Guys, I'm saying this not because I do not appreciate the time Con is >spending on it. I just hate to see time spent in the wrong priorities. >Whatever super privileged sleep->burn pattern you code, it can be >exploited w/out a global throttle for the CPU time assigned to interactive >and non interactive tasks. This is Unix guys and it is used in multi-user >environments, we cannot ship with a flaw like this.
(Oh, I agree that the problem is nasty. I like fair scheduling a lot... when _I'm_ not the one starving things to death;)
-Mike
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |