Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263069AbTHVGQw (ORCPT ); Fri, 22 Aug 2003 02:16:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263070AbTHVGQw (ORCPT ); Fri, 22 Aug 2003 02:16:52 -0400 Received: from pop.gmx.de ([213.165.64.20]:1414 "HELO mail.gmx.net") by vger.kernel.org with SMTP id S263069AbTHVGQo (ORCPT ); Fri, 22 Aug 2003 02:16:44 -0400 Message-Id: <5.2.1.1.2.20030822072356.01a22be0@pop.gmx.net> X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 22 Aug 2003 07:34:22 +0200 To: Wes Janzen From: Mike Galbraith Subject: Re: [PATCH] O17int Cc: Con Kolivas , Voluspa , linux kernel mailing list , Andrew Morton In-Reply-To: <3F454532.4030200@sbcglobal.net> References: <5.2.1.1.2.20030821154224.01990b48@pop.gmx.net> <5.2.1.1.2.20030821090657.00b45af8@pop.gmx.net> <200308210723.42789.kernel@kolivas.org> <5.2.1.1.2.20030821090657.00b45af8@pop.gmx.net> <5.2.1.1.2.20030821154224.01990b48@pop.gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5881 Lines: 110 At 05:18 PM 8/21/2003 -0500, Wes Janzen wrote: >Mike Galbraith wrote: > >>> less I throttled that, the less effective the antistarvation was. However >>>this is clearly a problem without using up full timeslices. I originally >>>thought they weren't trying to schedule lots because of the drop in ctx >>>during starvation but I forgot that rescheduling the same task doesnt count >>>as a ctx. >> >> >>Hmm. In what way did it hurt interactivity? I know that if you pass the >>cpu off to non-gui task who's going to use his full 100 ms slice, you'll >>definitely feel it. (made workaround, will spare delicate tummies;) If >>you mean that, say X releases the cpu and has only a couple of ms left on >>it's slice and is alone in it's queue, that preempting it at the end of >>it's slice after having only had the cpu for such a short time after >>wakeup hurts, you can qualify the preempt decision with a cpu possession >>time check. > >I wish I could get mm3 running so I could evaluate those interactivity >statements. I can't imagine it being worse than what I'm experiencing now: > >9 0 63968 21992 19672 319056 0 0 0 46 1231 289 87 13 >0 0 >5 0 63968 21096 19704 320020 0 0 0 26 1202 300 86 14 0 0 >14 0 63968 21104 19704 320020 0 0 0 0 1578 385 86 14 0 0 >8 0 63968 20448 20152 320048 0 0 7 41 1189 294 91 >9 0 0 >15 0 63968 19552 20132 321052 0 0 6 76 5926 1330 87 13 0 0 >13 0 63968 18992 20132 321664 0 0 0 31 5464 1266 87 13 0 0 >11 0 63968 18676 20100 321976 0 0 0 65 4613 1008 87 13 0 0 >8 0 63968 18044 20100 322660 0 0 0 14 4643 1132 87 13 0 0 >16 0 63968 17660 20100 323024 0 0 0 20 5273 1272 87 13 0 0 >14 0 63968 12092 20060 328596 0 0 0 24 5110 1221 87 13 0 0 >14 0 63968 11644 20052 329052 0 0 0 68 5264 1285 87 13 0 0 >13 0 63968 11324 19924 329560 0 0 0 34 4473 1125 87 13 0 0 >16 0 63968 10740 19964 329880 0 0 1 74 1494 445 90 10 0 0 >procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- >r b swpd free inact active si so bi bo in cs us sy id wa >22 0 63968 10452 19968 330300 0 0 1 51 4584 1059 88 12 0 0 >14 0 63968 10004 19940 330736 0 0 0 90 6567 1547 87 13 0 0 >15 0 63968 9188 20048 331472 5 0 10 106 5176 1289 87 13 0 0 >13 0 63968 13932 20016 326824 6 0 6 26 6026 1318 87 13 0 0 >12 0 63968 13412 19984 327324 0 0 0 24 4683 1083 87 13 0 0 >13 1 63968 12700 20012 327956 0 0 16 46 5673 1313 87 13 0 0 >12 0 63968 12252 20084 328296 0 0 6 78 3499 780 88 12 0 0 >18 0 63968 11468 20060 329016 0 0 0 35 5456 1231 87 13 0 0 >13 0 63968 12052 20096 328580 0 0 3 96 4430 988 87 13 0 0 >13 0 63968 5012 19144 336532 0 0 0 62 5672 1225 88 12 0 0 >16 0 63964 6624 17976 336088 0 0 0 297 4808 1041 88 12 0 0 >11 0 63964 5616 17964 337124 0 0 0 69 5219 1094 89 11 0 0 >16 1 63964 6732 15688 338276 13 0 20 155 4984 1156 87 13 0 0 >4 1 63964 7772 12544 340436 13 0 20 11 1070 201 90 10 0 0 >3 1 63964 4364 11560 344840 0 0 86 338 1038 250 92 >8 0 0 > > >That would be compiling the kernel, bunzipping a file, and some cron mandb >thing that was running gzip in the background niced. Plus X and Mozilla, >which probably starts the problem. At the end there, you see things calm >down. That's also the way it starts out, then something sets off the >"priority inversion" and the machine becomes completely worthless. Even >the task that are running aren't really accomplishing anything. So the >load goes from around 4/5 into the teens and the context switching makes a >corresponding jump. And then both interactivity AND throughput fall >through the floor. > >I can't imagine any interactivity regressions that are worse than this >behavior... > >And this happens with just X and Mozilla running. It happens less often >without X running, but still happens. Even if I'm at a VT, it could take >5-6 seconds for my text to appear after I type. This happens all the >time, about once every few minutes and correlates with a simultaneous >increase in context switches and load. Those high interrupt counts are all stalls? What kernel is that? >>> Also I recall that winegames got much better in O10 when everything was >>>charged at least one jiffy (pre nanosecond timing) suggesting those that >>>were >>>waking up for minute amounts of time repeatedly were being penalised; thus >>>taking out the possibility of the starving task staying high priority for >>>long. >> >> >>(unsure what you mean here) > >Can you set a cutoff point where if the process uses less that X percent >of the max timeslice, it is penalized? I don't know if it's possible >to do a loop of empty spins at some point and time it to find out what the >cut-off point should be...otherwise I imagine it would need to be tuned >for every processor speed. Could you use the bogomips to gauge the speed >of the machine and use that to determine the min timeslice? > From what I understand above, that would perhaps be more selective than > just penalizing every process and have a positive affect on > everything...of course I'm open to the possibility that I have it all wrong ;-) > >Wes > - 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/