* Dave Airlie <[EMAIL PROTECTED]> wrote:
> int slots = ( RADEON_READ( RADEON_RBBM_STATUS )
> & RADEON_RBBM_FIFOCNT_MASK );
> if ( slots >= entries ) return 0;
> - DRM_UDELAY( 1 );
> +
> + if (need_resched()) {
> + cond_resched();
> + }
> +
> + if (( i & 127 ) == 127 ) {
> + msleep(1);
> + }
> + // DRM_UDELAY( 1 );
do you have CONFIG_PREEMPT or CONFIG_SMP & CONFIG_DEBUG_SPINLOCK_SLEEP
turned on? You will get the atomicity asserts from schedule() only in a
preempt (or smp+debug) kernel, not in a normal UP kernel.
if it's indeed safe to reschedule then i'd suggest to do it like this:
cond_resched()
if (i > 100)
msleep(1);
else
DRM_UDELAY(1);
this way the polling limit is ~100 usecs, and reschedules are done
immediately. I dont think there's any point in continuing to poll for
127 iterations after the first 1 msec sleep.
btw., do you see any performance impact from the msleep(1)? Also, can
you see any CPU overhead reduction in games?
To test this easier you can do the following hack:
extern int panic_timeout;
if (!panic_timeout) {
cond_resched()
if (i > 100)
msleep(1);
else
DRM_UDELAY(1);
} else
DRM_UDELAY(1);
and you can trigger the original polling code via:
echo 1 > /proc/sys/kernel/panic
and trigger your new code via:
echo 0 > /proc/sys/kernel/panic
and watch how FPS and CPU utilization changes. It is easier to test the
change this way than to recompile & reboot the kernel. (it also makes
testing more reliable.)
Ingo
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
