public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Bill Davidsen <davidsen@tmr.com>
Cc: Linux Kernel M/L <linux-kernel@vger.kernel.org>
Subject: Re: [REPORT] 2.6.21 vs. 2.6.21-sd046 vs. 2.6.21-CFSv7
Date: Mon, 30 Apr 2007 15:58:45 -0400	[thread overview]
Message-ID: <46364A75.9080003@tmr.com> (raw)
In-Reply-To: <463643A9.5040009@tmr.com>

Bill Davidsen wrote:
> System: Intel 6600 Core2duo, 2GB RAM, X nice 0 for all tests, display 
> using i945G framebuffer
> 
> Test: playing a 'toon with mplayer while kernel build -j20 running.
> 
> Tuning: not yet, all scheduler parameters were default
> 
> Result: base 2.6.21 showed some pauses and after the pause the sound got 
> louder for a short time (<500ms). With sd-0.46 the playback had many 
> glitches and finally just stopped with the display looping on a small 
> number of frames and no sound. The skips were repeatable, the hang was 
> only two of five runs, I didn't let them go until the make finished 
> (todo list) but killed the mplayer after 10-15 sec. No glitches observed 
> with cfsv7, I thought I saw one but repeating with granularity set to 
> 500000 and then with no make running convinced me that it's just a 
> crappy piece of animation at that point.
> 
> I ran glxgears, again sd-0.46 had frequent pauses and uneven fps 
> reported. Stock 2.6.21 had a visible pause when the frame rate was 
> output, otherwise minimal pauses. CFSv7 appeared smooth at about 250 fps.
> 
> All tests gave acceptable typing echo, it seems that X is getting enough 
> time at that load to echo without major issues.
> 
> I will be doing tests with server load later this week, have to add disk 
> for the database.
> 
> Hope this initial report is useful, I may be able to update ctxbench 
> later today and try that.
> 
Followup: I reran with sd-0.46, setting rr_interval to 40, and then 5 
(default was 16). Neither appeared to give a useful video playback. I 
did try setting the make to nice 10, and that made the playback 
perfectly smooth, as well as response to skip forward and volume change 
happening when the key was pressed instead of eventually.

I also tried raising the nice of X to -10, that made things better on 
display, but I winder if it will let X run ahead of the nice-0 raid threads.

Is this my hardware or is there a really odd behavior here? The sd seems 
to be too fair to cope well with this realistic load, and expecting 
users to nice things is probably morally correct but unrealistic.

  reply	other threads:[~2007-04-30 19:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-30 19:29 [REPORT] 2.6.21 vs. 2.6.21-sd046 vs. 2.6.21-CFSv7 Bill Davidsen
2007-04-30 19:58 ` Bill Davidsen [this message]
2007-04-30 20:16   ` Bill Huey
2007-05-02 15:11     ` Bill Davidsen
2007-04-30 22:51 ` Con Kolivas
2007-05-02 15:18   ` Bill Davidsen

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=46364A75.9080003@tmr.com \
    --to=davidsen@tmr.com \
    --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