Wine device drivers proposal
Andreas Mohr
andi at rhlx01.fht-esslingen.de
Mon Apr 4 02:53:17 CDT 2005
Hi,
On Mon, Apr 04, 2005 at 08:58:32AM +1000, Troy Rollo wrote:
> Of course such a mechanism would be much slower than a native driver, and may
> run into problems with timing issues. Interrupts pose a particular challenge
> in that ideally the process handling the device should be activated
> immediately, and the Linux kernel currently provides no interface to say
> "switch to this task now" - the scheduler code simply does not provide for it
> (which is a shame, because a directed yield call with an associated call to
> return the remainder of the donated time slice(*) to the donor would be a
> "simple" way of radically improving the performance of anything that uses
> wineserver).
AFAIR (some recent discussion?) there were good reasons for not implementing
that, since it isn't all that helpful. But I'm not sure...
> So, input an output instructions: possible but likely to be slow, sometimes
> unacceptably slow. Interrupts are more of a problem due to the inability to
> do a directed yield.
>
> If you seriously want to attempt this, I would suggest your first port of call
> would be to the kernel list to discuss the possibility of implementing
> directed yield.
Nope, that should probably be the Con Kolivas list, since they do a LOT more
about scheduling things.
An interesting experiment could be using a recent Con Kolivas kernel
(2.6.11-ck3) and installing schedtoold and let wineserver run in isochronous
scheduling (SCHED_ISO). Then try some "nice" games to see what happens...
Andreas Mohr
More information about the wine-devel
mailing list