public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: James Cloos <cloos@jhcloos.com>, Ingo Molnar <mingo@elte.hu>
Cc: Matt Mackall <mpm@selenic.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	akpm@linux-foundation.org
Subject: Re: 2.6.21-rc3-mm1 RSDL results
Date: Sun, 11 Mar 2007 23:52:13 +1100	[thread overview]
Message-ID: <200703112352.13839.kernel@kolivas.org> (raw)
In-Reply-To: <m38xe4vtsn.fsf@lugabout.jhcloos.org>

On Sunday 11 March 2007 23:38, James Cloos wrote:
> |> See:
> |> http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/drivers/dri/r200/r200_i
> |>octl.c?revision=1.37&view=markup
>
> OK.
>
> Mesa is in git, now, but that still applies.  The gitweb url is:
>
> http://gitweb.freedesktop.org/?p=mesa/mesa.git
>
> and for the version of the above file in the master branch:
>
> http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=blob;f=src/mesa/drivers/dr
>i/r200/r200_ioctl.c
>
> The recursive grep(1) on mesa shows:
>
> ,----[grep -r sched_yield mesa]
>
> | mesa/mesa/src/mesa/drivers/dri/r300/radeon_ioctl.c:	    sched_yield();
> | mesa/mesa/src/mesa/drivers/dri/i915tex/intel_batchpool.c:     
> | sched_yield();
> | mesa/mesa/src/mesa/drivers/dri/i915tex/intel_batchbuffer.c:        
> | sched_yield(); mesa/mesa/src/mesa/drivers/dri/common/vblank.h:#include
> | <sched.h>   /* for sched_yield() */
> | mesa/mesa/src/mesa/drivers/dri/common/vblank.h:#include <sched.h>   /*
> | for sched_yield() */ mesa/mesa/src/mesa/drivers/dri/common/vblank.h:     
> | sched_yield();							\
> | mesa/mesa/src/mesa/drivers/dri/unichrome/via_ioctl.c:      sched_yield();
> | mesa/mesa/src/mesa/drivers/dri/i915/intel_ioctl.c:	 sched_yield();
> | mesa/mesa/src/mesa/drivers/dri/r200/r200_ioctl.c:       sched_yield();
>
> `----
>
> Thanks for the heads up.  I must've grep(1)ed the xorg subdir rather
> than the parent dir, and so missed mesa.

I just wonder what the heck all these will do to testing when using any of 
these drivers. Whether or not we do no yield, mild yield or full blown 
expiration yield, somehow or other I can't get over the feeling that if the 
code relies on yield() we can't really trust them to be meaningful cpu 
scheduler tests. This means most 3d apps out there that aren't using binary 
drivers, whether they be (fscking) glxgears, audio app visualisations or 
what...

-- 
-ck

  reply	other threads:[~2007-03-11 12:52 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-09  5:39 2.6.21-rc3-mm1 RSDL results Matt Mackall
2007-03-09  6:28 ` Con Kolivas
2007-03-09  7:53   ` Matt Mackall
2007-03-09  8:20     ` Matt Mackall
2007-03-09  8:39       ` Con Kolivas
2007-03-09 18:27         ` Matt Mackall
2007-03-09 20:15           ` Con Kolivas
2007-03-09 20:26             ` Con Kolivas
2007-03-09 20:51               ` Matt Mackall
2007-03-09 20:55             ` Matt Mackall
2007-03-09 20:46         ` Matt Mackall
2007-03-09 21:07           ` Con Kolivas
2007-03-09 21:19             ` Con Kolivas
2007-03-09 21:39               ` Matt Mackall
2007-03-09 21:57                 ` Con Kolivas
2007-03-09 22:18                   ` Con Kolivas
2007-03-09 22:29                     ` Matt Mackall
2007-03-09 23:02                       ` Con Kolivas
2007-03-09 23:06                         ` Matt Mackall
2007-03-10  0:31                           ` Con Kolivas
2007-03-10  0:34                       ` Con Kolivas
2007-03-10  0:49                         ` Matt Mackall
2007-03-10  1:28                           ` Con Kolivas
2007-03-10  1:42                             ` Matt Mackall
2007-03-10  2:10                               ` Kyle Moffett
2007-03-10  2:20                               ` Con Kolivas
2007-03-10  2:26                                 ` Matt Mackall
2007-03-10  2:53                                   ` Con Kolivas
2007-03-09 21:57                 ` Willy Tarreau
2007-03-09 22:12                   ` Con Kolivas
2007-03-09 22:20                     ` Matt Mackall
2007-03-09 22:31                     ` Willy Tarreau
2007-03-10  1:02                     ` Con Kolivas
2007-03-10  1:10                       ` Matt Mackall
2007-03-10 17:01             ` James Cloos
2007-03-10 23:16               ` Con Kolivas
2007-03-11 12:38                 ` James Cloos
2007-03-11 12:52                   ` Con Kolivas [this message]
2007-03-09 21:10           ` Matt Mackall
2007-03-09  8:36     ` Con Kolivas
2007-03-09  9:07       ` Serge Belyshev
2007-03-09  9:49         ` William Lee Irwin III
2007-03-09 10:36           ` Serge Belyshev
2007-03-09 18:07             ` Mark Lord
2007-03-09 18:24               ` Jeffrey Hundstad
2007-03-09 20:23               ` Con Kolivas
2007-03-10 18:21                 ` Mark Lord
2007-03-10 23:34                   ` Con Kolivas
2007-03-10 23:38                     ` Con Kolivas
2007-03-13 18:21                     ` Mark Lord
2007-03-13 20:26                       ` Con Kolivas
2007-03-13 22:06                         ` Mark Lord

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=200703112352.13839.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=akpm@linux-foundation.org \
    --cc=cloos@jhcloos.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mpm@selenic.com \
    /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