* [PATCH] O6.1int @ 2003-07-17 2:13 Con Kolivas 2003-07-17 2:39 ` Wade ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Con Kolivas @ 2003-07-17 2:13 UTC (permalink / raw) To: linux kernel mailing list; +Cc: Andrew Morton, Wade, Eugene Teo, Wiktor Wodecki The bug in the O6int patch probably wasn't responsible for WIktor's problem actually. It shouldn't manifest for a very long time. Anyway here is the fix and a couple of minor cleanups. --- linux-2.6.0-test1-mm1/kernel/sched.c 2003-07-17 11:24:54.000000000 +1000 +++ linux-2.6.0-testck1/kernel/sched.c 2003-07-17 11:59:01.000000000 +1000 @@ -78,7 +78,7 @@ #define STARVATION_LIMIT (10*HZ) #define SLEEP_BUFFER (HZ/100) #define NODE_THRESHOLD 125 -#define MAX_BONUS (40 * PRIO_BONUS_RATIO / 100) +#define MAX_BONUS (MAX_USER_PRIO * PRIO_BONUS_RATIO / 100) /* * If a task is 'interactive' then we reinsert it in the active @@ -390,8 +390,6 @@ static inline void activate_task(task_t long sleep_time = jiffies - p->last_run - 1; if (sleep_time > 0) { - unsigned long runtime = jiffies - p->avg_start; - /* * Tasks that sleep a long time are categorised as idle and * will get just under interactive status with a small runtime @@ -402,6 +400,11 @@ static inline void activate_task(task_t p->sleep_avg = MIN_SLEEP_AVG * (MAX_BONUS - INTERACTIVE_DELTA - 2) / MAX_BONUS; } else { + unsigned long runtime = jiffies - p->avg_start; + + if (runtime > MAX_SLEEP_AVG) + runtime = MAX_SLEEP_AVG; + /* * This code gives a bonus to interactive tasks. * ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] O6.1int 2003-07-17 2:13 [PATCH] O6.1int Con Kolivas @ 2003-07-17 2:39 ` Wade 2003-07-17 7:45 ` Felipe Alfaro Solana [not found] ` <20030717045435.GA630@lorien.emufarm.org> 2 siblings, 0 replies; 14+ messages in thread From: Wade @ 2003-07-17 2:39 UTC (permalink / raw) To: Con Kolivas; +Cc: linux-kernel Con Kolivas wrote: > The bug in the O6int patch probably wasn't responsible for WIktor's problem > actually. It shouldn't manifest for a very long time. Anyway here is the fix > and a couple of minor cleanups. Thanks Con! Running the modified 06.1 patch now. With the previous patch I did notice a slowdown of X in general over time (slow repainting and such). Lets see how this one goes... ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] O6.1int 2003-07-17 2:13 [PATCH] O6.1int Con Kolivas 2003-07-17 2:39 ` Wade @ 2003-07-17 7:45 ` Felipe Alfaro Solana 2003-07-17 7:53 ` Con Kolivas [not found] ` <20030717045435.GA630@lorien.emufarm.org> 2 siblings, 1 reply; 14+ messages in thread From: Felipe Alfaro Solana @ 2003-07-17 7:45 UTC (permalink / raw) To: Con Kolivas Cc: linux kernel mailing list, Andrew Morton, Wade, Eugene Teo, Wiktor Wodecki On Thu, 2003-07-17 at 04:13, Con Kolivas wrote: > The bug in the O6int patch probably wasn't responsible for WIktor's problem > actually. It shouldn't manifest for a very long time. Anyway here is the fix > and a couple of minor cleanups. This is even better than plain O6-int. Everything is nearly perfect. One thing I dislike a bit is that on my slow PIII 700Mhz, moving a medium-sized window over Evolution 1.4.3 main window (displaying my INBOX full of messages) makes the window movement a little jumpy (Evolution 1.4.3 is well-known to be a serious CPU hogger when repainting windows). Renicing X to -20 helps a little with the jumpiness. Nice work, indeed! ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] O6.1int 2003-07-17 7:45 ` Felipe Alfaro Solana @ 2003-07-17 7:53 ` Con Kolivas 0 siblings, 0 replies; 14+ messages in thread From: Con Kolivas @ 2003-07-17 7:53 UTC (permalink / raw) To: Felipe Alfaro Solana Cc: linux kernel mailing list, Andrew Morton, Wade, Eugene Teo, Wiktor Wodecki On Thu, 17 Jul 2003 17:45, Felipe Alfaro Solana wrote: > On Thu, 2003-07-17 at 04:13, Con Kolivas wrote: > > The bug in the O6int patch probably wasn't responsible for WIktor's > > problem actually. It shouldn't manifest for a very long time. Anyway here > > is the fix and a couple of minor cleanups. > > This is even better than plain O6-int. Everything is nearly perfect. > One thing I dislike a bit is that on my slow PIII 700Mhz, moving a > medium-sized window over Evolution 1.4.3 main window (displaying my > INBOX full of messages) makes the window movement a little jumpy > (Evolution 1.4.3 is well-known to be a serious CPU hogger when > repainting windows). Thanks. That one I _do_ know about, and am still thinking about a fair way to fix. Con ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <20030717045435.GA630@lorien.emufarm.org>]
[parent not found: <200307171712.20193.kernel@kolivas.org>]
[parent not found: <200307171635.25730.kernel@kolivas.org>]
* Re: [PATCH] O6.1int [not found] ` <200307171635.25730.kernel@kolivas.org> @ 2003-07-17 8:04 ` Danek Duvall 2003-07-17 8:21 ` Con Kolivas 2003-07-18 7:07 ` Danek Duvall 0 siblings, 2 replies; 14+ messages in thread From: Danek Duvall @ 2003-07-17 8:04 UTC (permalink / raw) To: Con Kolivas; +Cc: linux-kernel On Thu, Jul 17, 2003, Con Kolivas wrote: > Thanks for testing. How does vanilla 2.6.0-test1 compare? About the same, actually. There are a few differences, but I can't call one better or worse. > Can you watch top while all this is running, and see what dynamic > priority these applications are during this (the cc's, X, mozilla, > xterm and xmms), and when their behavious is less than ideal what the > priority is. In 2.6.0-test1, the cc1 processes hover around 30 (early on they're lower, but they ramp up quickly). Xmms stays fixed at 20 pretty much the entire time. X stays fixed at 15, though sometimes with heavy window moving it'll skyrocket to 16. :) Mozilla typically is at 20, but after lots of scrolling, it edges up slowly (and, I think, pretty linearly) to 30. Scrolling's bad by the time you get to 23 (with the compile going; if it's the only interesting thing happening, it's smooth all the way up). The jerkiness in mozilla scrolling repeatedly takes three to four seconds before it shows up. Let it sit for a few more seconds and it's good to go again, at least for another three to four seconds. The python process updating the portage database is in the 23-25 range. In 2.6.0-test1-mm1 with O6.1int, mozilla takes longer to get jerky (15-20 seconds), but once it does, it gets stuck there pretty bad. Over the 16 minutes it took to compile the kernel, I think I managed to get it unstuck twice (maybe I didn't know how to do it right -- I kept poking at it and maybe that was the wrong thing to do). When left alone, it would settle at 24, though it would drop to 20 or 21 when either raised to the top of the window stack or lowered to the bottom (I'm using fvwm, in case that matters here). It would come back up to 24 within a second or two. Any scrolling instantly brought it up to 27 and climbing. X, cc1, and xmms all had the same behavior as in vanilla (roughly the same amount of skippiness). The python process had a lower priority, spending most of its time in the 17-20 range. One other thing -- xmms skips seem to cause it to spit out ** WARNING **: snd_pcm_wait: Input/output error ** WARNING **: Buffer time reduced from 500 ms to 371 ms Not consistently one or the other or both, but at least one of those would show up each time. Hope this helps, Danek ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] O6.1int 2003-07-17 8:04 ` Danek Duvall @ 2003-07-17 8:21 ` Con Kolivas 2003-07-17 8:52 ` Eugene Teo 2003-07-17 9:06 ` Mike Galbraith 2003-07-18 7:07 ` Danek Duvall 1 sibling, 2 replies; 14+ messages in thread From: Con Kolivas @ 2003-07-17 8:21 UTC (permalink / raw) To: Danek Duvall; +Cc: linux-kernel On Thu, 17 Jul 2003 18:04, Danek Duvall wrote: > In 2.6.0-test1, the cc1 processes hover around 30 (early on they're That's weird, unless you nice 5 them they shouldn't get any higher than 25. A quick code review doesn't reveal to me why that would be the case. > lower, but they ramp up quickly). Xmms stays fixed at 20 pretty much > the entire time. X stays fixed at 15, though sometimes with heavy Also weird; it's almost impossible to get stuck at the static priority. 20 is what a nice 5 application would be. > window moving it'll skyrocket to 16. :) Mozilla typically is at 20, Also sounds like nice 5 > but after lots of scrolling, it edges up slowly (and, I think, pretty > linearly) to 30. Scrolling's bad by the time you get to 23 (with the Same thing. > compile going; if it's the only interesting thing happening, it's smooth > all the way up). > > The jerkiness in mozilla scrolling repeatedly takes three to four > seconds before it shows up. Let it sit for a few more seconds and it's > good to go again, at least for another three to four seconds. > > The python process updating the portage database is in the 23-25 range. > > In 2.6.0-test1-mm1 with O6.1int, mozilla takes longer to get jerky > (15-20 seconds), but once it does, it gets stuck there pretty bad. Over > the 16 minutes it took to compile the kernel, I think I managed to get > it unstuck twice (maybe I didn't know how to do it right -- I kept > poking at it and maybe that was the wrong thing to do). When left > alone, it would settle at 24, though it would drop to 20 or 21 when > either raised to the top of the window stack or lowered to the bottom > (I'm using fvwm, in case that matters here). It would come back up to > 24 within a second or two. Any scrolling instantly brought it up to 27 > and climbing. Same. (how >25 ?) > > X, cc1, and xmms all had the same behavior as in vanilla (roughly the > same amount of skippiness). > > The python process had a lower priority, spending most of its time in > the 17-20 range. That's more consistent. > > One other thing -- xmms skips seem to cause it to spit out > > ** WARNING **: snd_pcm_wait: Input/output error > ** WARNING **: Buffer time reduced from 500 ms to 371 ms > > Not consistently one or the other or both, but at least one of those > would show up each time. Not sure what these really mean. > Hope this helps, Not entirely sure. I'll continue reviewing my code. Con ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] O6.1int 2003-07-17 8:21 ` Con Kolivas @ 2003-07-17 8:52 ` Eugene Teo 2003-07-17 9:06 ` Mike Galbraith 1 sibling, 0 replies; 14+ messages in thread From: Eugene Teo @ 2003-07-17 8:52 UTC (permalink / raw) To: Con Kolivas; +Cc: Danek Duvall, linux-kernel <quote sender="Con Kolivas"> > On Thu, 17 Jul 2003 18:04, Danek Duvall wrote: > > In 2.6.0-test1, the cc1 processes hover around 30 (early on they're > <snipped> Conman, Was running O6int, and after running my laptop for 1/2 day, I experienced obvious slowdown, and not just xmms is jittering, licq is not functioning smoothly, etc. Was running licq, xmms, couple of aterm, ssh. Prior to these, was running lmbench. Now running O6.1int, no problem at the moment, but noticable improvement especially when hiding/unhiding aterm (using wmaker). Will keep you updated. Specs: CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz stepping 04 Memory: 514732k/523776k available Linux philyra 2.6.0-test1-mm1+o6int #1 Thu Jul 17 11:11:55 SGT 2003 i686 /amnesia ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] O6.1int 2003-07-17 8:21 ` Con Kolivas 2003-07-17 8:52 ` Eugene Teo @ 2003-07-17 9:06 ` Mike Galbraith 1 sibling, 0 replies; 14+ messages in thread From: Mike Galbraith @ 2003-07-17 9:06 UTC (permalink / raw) To: Con Kolivas; +Cc: Danek Duvall, linux-kernel At 06:21 PM 7/17/2003 +1000, Con Kolivas wrote: >On Thu, 17 Jul 2003 18:04, Danek Duvall wrote: > > In 2.6.0-test1, the cc1 processes hover around 30 (early on they're > >That's weird, unless you nice 5 them they shouldn't get any higher than 25. A >quick code review doesn't reveal to me why that would be the case. Perhaps he has PRIO_BONUS_RATIO set to 50. -Mike ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] O6.1int 2003-07-17 8:04 ` Danek Duvall 2003-07-17 8:21 ` Con Kolivas @ 2003-07-18 7:07 ` Danek Duvall 2003-07-18 9:40 ` Rudo Thomas 2003-07-18 14:43 ` Valdis.Kletnieks 1 sibling, 2 replies; 14+ messages in thread From: Danek Duvall @ 2003-07-18 7:07 UTC (permalink / raw) To: Con Kolivas; +Cc: linux-kernel After fixing my nice +5 problem, I'm still seeing pretty much the same behavior, only with the priority values lowered by five. The entire desktop seems a bit snappier when not under load. I got significantly more skipping in xmms under 2.6.0-test1 than under the O6.1 patch this time, rather than the two being seemingly the same. The scrolling behavior in mozilla was pretty much identical to how I described it before. I did discover under O6.1int that I could make xmms block indefinitely when opening a window, with fvwm's wire frame manual placement, which I hadn't ever noticed before, but I'm not sure if that's because it actually wasn't there before, or I just placed the windows more quickly. So, ultimately, no real difference. Danek ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] O6.1int 2003-07-18 7:07 ` Danek Duvall @ 2003-07-18 9:40 ` Rudo Thomas 2003-07-18 9:45 ` Zwane Mwaikambo 2003-07-18 14:43 ` Valdis.Kletnieks 1 sibling, 1 reply; 14+ messages in thread From: Rudo Thomas @ 2003-07-18 9:40 UTC (permalink / raw) To: linux-kernel; +Cc: Danek Duvall, Con Kolivas > I did discover under O6.1int that I could make xmms block indefinitely > when opening a window, with fvwm's wire frame manual placement, which I > hadn't ever noticed before, but I'm not sure if that's because it > actually wasn't there before, or I just placed the windows more quickly. The latter, I think. I had similar problems under kwin when moving windows with "display window contents while moving" unset. I don't seem to be able to reproduce it now (2.6.0-t1), though. Rudo. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] O6.1int 2003-07-18 9:40 ` Rudo Thomas @ 2003-07-18 9:45 ` Zwane Mwaikambo 0 siblings, 0 replies; 14+ messages in thread From: Zwane Mwaikambo @ 2003-07-18 9:45 UTC (permalink / raw) To: Rudo Thomas; +Cc: linux-kernel, Danek Duvall, Con Kolivas On Fri, 18 Jul 2003, Rudo Thomas wrote: > > I did discover under O6.1int that I could make xmms block indefinitely > > when opening a window, with fvwm's wire frame manual placement, which I > > hadn't ever noticed before, but I'm not sure if that's because it > > actually wasn't there before, or I just placed the windows more quickly. > > The latter, I think. I had similar problems under kwin when moving windows with > "display window contents while moving" unset. I don't seem to be able to > reproduce it now (2.6.0-t1), though. Side note i can actually wiggle a mozilla window around a 2000x2000@24bit display with make -j2 going and 'display window contents while moving' now in KDE3 w/ kwin. I normally have it on wireframe. X server is the XFree86 radeon driver w/ a 9100 and 128Mb of video memory, system is dual 400, 512Mb ram. -- function.linuxpower.ca ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] O6.1int 2003-07-18 7:07 ` Danek Duvall 2003-07-18 9:40 ` Rudo Thomas @ 2003-07-18 14:43 ` Valdis.Kletnieks 2003-07-18 14:47 ` Danek Duvall 2003-07-18 14:52 ` Con Kolivas 1 sibling, 2 replies; 14+ messages in thread From: Valdis.Kletnieks @ 2003-07-18 14:43 UTC (permalink / raw) To: Danek Duvall; +Cc: Con Kolivas, linux-kernel [-- Attachment #1: Type: text/plain, Size: 531 bytes --] On Fri, 18 Jul 2003 00:07:49 PDT, Danek Duvall said: > I did discover under O6.1int that I could make xmms block indefinitely > when opening a window, with fvwm's wire frame manual placement, which I > hadn't ever noticed before, but I'm not sure if that's because it > actually wasn't there before, or I just placed the windows more quickly. This could be a result of fvwm grabbing the X server while the wireframe stuff is going on, and xmms being blocked trying to update the image on screen (think "scrolling song title" ;) [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] O6.1int 2003-07-18 14:43 ` Valdis.Kletnieks @ 2003-07-18 14:47 ` Danek Duvall 2003-07-18 14:52 ` Con Kolivas 1 sibling, 0 replies; 14+ messages in thread From: Danek Duvall @ 2003-07-18 14:47 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 600 bytes --] Valdis.Kletnieks@vt.edu wrote: > This could be a result of fvwm grabbing the X server while the > wireframe stuff is going on, and xmms being blocked trying to update > the image on screen (think "scrolling song title" ;) Yah, I'm pretty sure that's what it is. I just tried it again, and I couldn't get it to happen again, but, like I'd expect, none of the graphics (anywhere on the screen) updated with the wireframe up. I'd guess xmms has some incorrect synchronization between its audio and display threads, and I just happened to be hitting that consistently last night, but not now. Danek [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] O6.1int 2003-07-18 14:43 ` Valdis.Kletnieks 2003-07-18 14:47 ` Danek Duvall @ 2003-07-18 14:52 ` Con Kolivas 1 sibling, 0 replies; 14+ messages in thread From: Con Kolivas @ 2003-07-18 14:52 UTC (permalink / raw) To: Valdis.Kletnieks, Danek Duvall; +Cc: linux-kernel On Sat, 19 Jul 2003 00:43, Valdis.Kletnieks@vt.edu wrote: > On Fri, 18 Jul 2003 00:07:49 PDT, Danek Duvall said: > > I did discover under O6.1int that I could make xmms block indefinitely > > when opening a window, with fvwm's wire frame manual placement, which I > > hadn't ever noticed before, but I'm not sure if that's because it > > actually wasn't there before, or I just placed the windows more quickly. > > This could be a result of fvwm grabbing the X server while the wireframe > stuff is going on, and xmms being blocked trying to update the image on > screen (think "scrolling song title" ;) I'm pretty sure if you were really unlucky you could hit just the wrong timing with O6.1 which might do this. O7 I believe addresses this. Con ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2003-07-18 15:06 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-07-17 2:13 [PATCH] O6.1int Con Kolivas 2003-07-17 2:39 ` Wade 2003-07-17 7:45 ` Felipe Alfaro Solana 2003-07-17 7:53 ` Con Kolivas [not found] ` <20030717045435.GA630@lorien.emufarm.org> [not found] ` <200307171712.20193.kernel@kolivas.org> [not found] ` <200307171635.25730.kernel@kolivas.org> 2003-07-17 8:04 ` Danek Duvall 2003-07-17 8:21 ` Con Kolivas 2003-07-17 8:52 ` Eugene Teo 2003-07-17 9:06 ` Mike Galbraith 2003-07-18 7:07 ` Danek Duvall 2003-07-18 9:40 ` Rudo Thomas 2003-07-18 9:45 ` Zwane Mwaikambo 2003-07-18 14:43 ` Valdis.Kletnieks 2003-07-18 14:47 ` Danek Duvall 2003-07-18 14:52 ` Con Kolivas
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).