From: Con Kolivas <kernel@kolivas.org>
To: Danek Duvall <duvall@emufarm.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] O6.1int
Date: Thu, 17 Jul 2003 18:21:41 +1000 [thread overview]
Message-ID: <200307171821.41886.kernel@kolivas.org> (raw)
In-Reply-To: <20030717080436.GA16509@lorien.emufarm.org>
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
next prev parent reply other threads:[~2003-07-17 8:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200307171821.41886.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=duvall@emufarm.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).