Messages in this thread | | | Date | Fri, 18 Apr 2003 15:58:41 +0200 | From | Mike Galbraith <> | Subject | Re: Bad interactive behaviour in 2.5.65-66 (sched.c) |
| |
At 08:35 AM 3/31/2003 +0200, Jens Axboe wrote: >On Mon, Mar 31 2003, Mike Galbraith wrote: > > At 07:06 AM 3/31/2003 +1000, Con Kolivas wrote: > > >On Mon, 31 Mar 2003 00:14, Jens Axboe wrote: > > >> On Sat, Mar 29 2003, Robert Love wrote: > > >> > On Sat, 2003-03-29 at 21:33, Con Kolivas wrote: > > >> > > Are you sure this should be called a bug? Basically X is an > > >interactive > > >> > > process. If it now is "interactive for a priority -10 process" then > > >it > > >> > > should be hogging the cpu time no? The priority -10 was a workaround > > >> > > for lack of interactivity estimation on the old scheduler. > > >> > > > >> > Well, I do not necessarily think that renicing X is the problem. Just > > >> > an idea. > > >> > > >> I see the exact same behaviour here (systems appears fine, cpu intensive > > >> app running, attempting to start anything _new_ stalls for ages), and I > > >> definitely don't play X renice tricks. > > >> > > >> It basically made 2.5 unusable here, waiting minutes for an ls to even > > >> start displaying _anything_ is totally unacceptable. > > > > > >I guess I should have trusted my own benchmark that was showing this was > > >worse > > >for system responsiveness. > > > > I don't think it's really bad for system responsiveness. I think the > >What drugs are you on? 2.5.65/66 is the worst interactive kernel I've >ever used, it would be _embarassing_ to release a 2.6-test with such a >rudimentary flaw in it. IOW, a big show stopper.
Hehehe... try the attached if you're brave. It took me a loooong time to get backboost to work right. Mainly because backboost wasn't really broken :))) This patch _needs_ backboost to work, (see sleep_avg_tick()) and it does seem to do the job very nicely.
> > problem is just that the sample is too small. The proof is that simply > > doing sleep_time %= HZ cures most of my woes. WRT contest and it's
The real problem is that there is no information in the fact that you were in lala land for a year or so. Just because you slept through lunch, there's nothing that says you'll be a good mood afterward. The useful information is the fact that someone else got a chance at the cpu, and you're only a really nice guy if you share a lot. Take a look at what I did to activate_task()... if you slept for a short time, use that information. If you slept for a long time, you get exactly what you need to finish your time slice. This isn't subject to the number of tasks queued up, so the mistakes are smaller. I also dispose of mistakes faster to make sure that interactive tasks (which aren't once they start running a lot) don't eat ages of cpu. With this patch, I can get more than one task from a make -j30 bzImage in an ext3 partition to run concurrently, _and_ X is wonderful as well (gee, I really can have my cake and eat it too:).
> Irk, that sounds like a really ugly bandaid.
Well, it was just tossing the most damaging part of the problem into the bit bucket.
Anyway, anyone who thinks the scheduler is still unfair, or el-sucko in any way should feel free to beat upon this experiment. I really like this one... think I'll even keep my fingers off it for a few minutes ;-)
-Mike
Yeah, some of it _is_ gratuitous, but heck, it's almost pure research. (no kaBoOMs... yet) [unhandled content-type:application/octet-stream] | |