public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <piggin@cyberone.com.au>
To: "Murray J. Root" <murrayr@brain.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.0-testX - strange scheduling(?) problem
Date: Mon, 22 Sep 2003 14:28:58 +1000	[thread overview]
Message-ID: <3F6E7A8A.8010604@cyberone.com.au> (raw)
In-Reply-To: <20030922024058.GA1348@Master>



Murray J. Root wrote:

>On Wed, Sep 17, 2003 at 03:22:41PM +1000, Nick Piggin wrote:
>
>>
>>Murray J. Root wrote:
>>
>>
>>>P4 2G
>>>1G PC2700 RAM
>>>GF2 GTS video (nv drivers, not nvidia)
>>>
>>>In all 2.6.0-test versions (1-5) I get very odd issues when using 
>>>cpu+memory
>>>intense apps. Using POV-Ray 3.5, for example:
>>>When I render an image I get about 15k pixels per second and the system is
>>>usable and responsive in other apps, most of the time.
>>>About 20% of the time the pixels-per-second is only 3k, the system is at
>>>nearly a standstill, and other apps barely function.
>>>I've tested it many times using the exact same image and the behavior is
>>>very consistent. Other apps do the same, but since I can't get a consistent
>>>starting state with them, I used POV-Ray for the testing.
>>>The slowdown is so bad that the screen can take as long as 2 seconds to 
>>>refresh, opening a term can take as much as 15 seconds.
>>>Stopping the render and restarting it fixes it about 1/2 the time. Stopping
>>>the render and switching to another app, then restarting the render fixes
>>>it about 1/2 the time. Enough stop & restarts always fixes it eventually.
>>>There doesn't appear to be any memory leakage, and the system isn't going
>>>into swap. Top shows the same numbers in all cases. Time of day, other 
>>>apps running, etc. makes no difference.
>>>
>>>
>>Hi Murray,
>>Thanks for reporting this. Its a very important issue. Would you please
>>try this patch:
>>http://ck.kolivas.org/patches/2.6/2.6.0-test5/patch-test5-O20int
>>on 2.6.0-test5, and report your results.
>>
>>If you get time, or if the above still has problems, you could try
>>http://www.kerneltrap.org/~npiggin/v15/sched-rollup-v15.gz
>>as well. Give priority to the first patch though, please.
>>
>>
>
>Using the first patch either fixed it or made it so rare I haven't seen it
>in 4 hours of testing.
>One side-effect - rendering seems to take about 20% longer, and top shows
>X using 20-25% cpu while rendering. Prior to 2.6.0-test[1-5] X never got
>up past 5% and generally hung around less than 1%.
>But user-feel is *much* better. No delays or "hangs" while typing or clicking
>even while running two renders at the same time.
>

CCing to the list. Sounds good. The longer rendering seems to be pretty
well in line with the CPU X is using. This is obviously fine and
desired. Thanks Murray, and good news, this patch will be included in
test6 as far as I can see.



  parent reply	other threads:[~2003-09-22  4:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-17  5:09 2.6.0-testX - strange scheduling(?) problem Murray J. Root
     [not found] ` <3F67EFA1.30005@cyberone.com.au>
     [not found]   ` <20030922024058.GA1348@Master>
2003-09-22  4:28     ` Nick Piggin [this message]
2003-09-22  4:48       ` 2.6.0-test5-bk8 breaks VMWare build J.C. Wren

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=3F6E7A8A.8010604@cyberone.com.au \
    --to=piggin@cyberone.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=murrayr@brain.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