All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Con Kolivas <kernel@kolivas.org>
Cc: ck@vds.kolivas.org, 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: Wed, 02 May 2007 11:18:44 -0400	[thread overview]
Message-ID: <4638ABD4.3040703@tmr.com> (raw)
In-Reply-To: <200705010851.41375.kernel@kolivas.org>

Con Kolivas wrote:
> On Tuesday 01 May 2007 05:29, Bill Davidsen wrote:
>   
>> System: Intel 6600 Core2duo, 2GB RAM, X nice 0 for all tests, display
>> using i945G framebuffer
>>     
>
> Bill thanks for testing.
>   
>> Test: playing a 'toon with mplayer while kernel build -j20 running.
>>     
>
> Umm I don't think make -j20 is a realistic load on 2 cores. Not only does it 
> raise your load to 20 but your I/O bandwidth will even be struggling. If 
> video playback was to be smooth at that size a load it would suggest some 
> serious unfairness. I'm not just pushing the fairness barrow here; I mean it 
> would need to be really really unfair unless your combined X and video 
> playback cpu combined added up to less than 1/20th of your total cpu power 
> (which is possible but I kinda doubt it). Do you really use make -j20 to 
> build regularly?
>
>   
Yes, this is a compile and file server, I frequently build a raft of 
kernels when a security patch comes out. There doesn't seem to be an i/o 
issue, with 2GB RAM and RAID5 over a SATA array I have enough, but 
honestly the disk activity is minimal, even with a single drive.
>> 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 did notice on your followup email that nice +10 of the 20 makes fixed the 
> playback which sounds pretty good.
>
>   
Yes, I can get around the load doing that.
>> 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.
>>     
>
> I assume you mean glxgears when you're running make -j20 again here.
>   
Of course. ;-)

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979


      reply	other threads:[~2007-05-02 15:16 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
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 [this message]

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=4638ABD4.3040703@tmr.com \
    --to=davidsen@tmr.com \
    --cc=ck@vds.kolivas.org \
    --cc=kernel@kolivas.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.