LKML Archive on
help / color / mirror / Atom feed
From: Con Kolivas <>
To: Bill Davidsen <>
Cc: Ingo Molnar <>, Ed Tomlinson <>,
	Linux Kernel M/L <>
Subject: Re: [REPORT] First "glitch1" results, 2.6.21-rc7-git6-CFSv5 + SD  0.46
Date: Fri, 27 Apr 2007 08:56:16 +1000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Friday 27 April 2007 08:00, Bill Davidsen wrote:
> Ingo Molnar wrote:
> > * Ed Tomlinson <> 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.

top by itself certainly cannot be trusted to give true representation of the 
cpu usage I'm afraid. It's not as convoluted as, say, trying to track memory 
usage of an application, but top's resolution being tied to HZ accounting 
makes it not reliable in that regard.
> 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.

I have a problem with your test case Bill. Its behaviour would depend on how 
gpu bound vs cpu bound vs accelerated vs non-accelerated your graphics card 
is. I get completely different results to those of the other testers given 
the different hardware configuration and I don't think my results are 
valuable. My problem with this testcase is - What would you define 
as "perfect" behaviour for your test case? It seems far too arbitrary.


  reply	other threads:[~2007-04-26 23:08 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
2007-04-26 22:56         ` Con Kolivas [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: [REPORT] First "glitch1" results, 2.6.21-rc7-git6-CFSv5 + SD  0.46' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).