From: Bill Davidsen <davidsen@tmr.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Ed Tomlinson <edt@aei.ca>, "Kolivas, Con" <kernel@kolivas.org>,
Linux Kernel M/L <linux-kernel@vger.kernel.org>,
Bill Davidsen <davidsen@tmr.com>
Subject: Re: [REPORT] First "glitch1" results, 2.6.21-rc7-git6-CFSv5 + SD 0.46
Date: Thu, 26 Apr 2007 18:00:54 -0400 [thread overview]
Message-ID: <46312116.1030506@tmr.com> (raw)
In-Reply-To: <20070424065709.GB19802@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]
Ingo Molnar wrote:
> * Ed Tomlinson <edt@aei.ca> wrote:
>
>>> SD 0.46 1-2 FPS
>>> cfs v5 nice -19 219-233 FPS
>>> cfs v5 nice 0 1000-1996
>> cfs v5 nice -10 60-65 FPS
>
> the problem is, the glxgears portion of this test is an _inverse_
> testcase.
>
> The reason? glxgears on true 3D hardware will _not_ use X, it will
> directly use the 3D driver of the kernel. So by renicing X to -19 you
> give the xterms more chance to show stuff - the performance of the
> glxgears will 'degrade' - but that is what you asked for: glxgears is
> 'just another CPU hog' that competes with X, it's not a "true" X client.
>
> if you are after glxgears performance in this test then you'll get the
> best performance out of this by renicing X to +19 or even SCHED_BATCH.
>
Several points on this...
First, I don't think this is accelerated in the way you mean, the
machine is a test server, with motherboard video using the 945G video
driver. Given the limitations of the support in that setup, I don't
think it qualified as "true 3D hardware," although I guess I could try
using the vesafb version as a test.
The 2nd thing I note is that on FC6 this scheduler seems to confuse
'top' to some degree, since the glxgears is shown as taking 51% of the
CPU (one core), while the state breakdown shows about 73% in idle,
waitio, and int. image attached.
After I upgrade the kernel and cfs to the absolute latest I'll repeat
this, as well as test with vesafb, and my planned run under heavy load.
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
[-- Attachment #2: top.png --]
[-- Type: image/png, Size: 58571 bytes --]
next prev parent reply other threads:[~2007-04-26 22:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-23 21:57 [REPORT] First "glitch1" results, 2.6.21-rc7-git6-CFSv5 Bill Davidsen
2007-04-23 23:45 ` [REPORT] First "glitch1" results, 2.6.21-rc7-git6-CFSv5 + SD 0.46 Ed Tomlinson
2007-04-23 23:49 ` Ed Tomlinson
2007-04-24 6:57 ` Ingo Molnar
2007-04-26 22:00 ` Bill Davidsen [this message]
2007-04-26 22:56 ` Con Kolivas
2007-04-27 2:52 ` Ed Tomlinson
2007-04-27 18:22 ` 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=46312116.1030506@tmr.com \
--to=davidsen@tmr.com \
--cc=edt@aei.ca \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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.