* Jon Smirl <[EMAIL PROTECTED]> wrote:
> --- Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > the cleanest and highest performing solution would be to have an
> > interrupt source for 3D completion - do you have such an interrupt
> > handler handy? If yes then you can sleep precisely up to completion:
>
> Interrupts are not a good solution. The hardware would generate
> millions of them per second. This is the same problem network cards
> have, you can interrupt the machine to death.
you'd only have to enable interrupt generation when you are not
busy-polling. In 99.9% of the cases (when !need_resched()) you could
busy poll as much as you want, and keep IRQ generation off. Very likely
IRQ generation can be turned on/off via a single PCI write on most 3D
hardware. Anyway, IRQ generation would just be a 'nice' thing. But the
following property is a must:
> I would expect the best solution is to make a few passes through the
> loop delaying a couple usec to catch the common case of quick
> completion. Then switch to doing need_resched().
no. If need_resched() is set then the code *must* try to schedule ASAP.
There is no excuse for not doing so - 'performance will suffer' is not a
correct argument becase _if_ need_resched() is true then the system (and
the user) doesnt want the 3D app to run right now. There will be no
performance difference to the 3D app, since by having high latencies the
DRI code does not give any extra performance to 3D apps, it only
increases the scheduling latency! The timeslices of the 3D app are used
up depending on how long the 3D app runs - so if it burns cycles
busy-polling it will in fact get less CPU time on average. (if the CPU
is contended.)
Anyway, need_resched() set is not a common condition, and if it happens
then kernel code _must_ react. (In fact most kernel code will be
preempted right away - but the DRI code runs under spinlocks.)
So the correct solution is to add something like this to _at least_ the
busy-polling code:
if (need_resched()) {
... drop locks ...
cond_resched();
... reacquire locks ...
}
or, if there's a single spinlock held (the BKL doesnt count) then:
cond_resched_lock(&driver->lock);
(but the locking obviously has to be correct and safe.)
ok?
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
