Hi!
> > testing the patch complaining about, AND one that seems like it could be
> > addressed by using IRQ disabling as a latency guard in addition to spinlocks.
>
> I dont believe anyone has tested the driver hard with pre-empt. Its not that
> this driver can't be fixed. Its that this is one tiny example of maybe
> thousands of other similar flaws lurking. There is no obvious automated way
> to find them either.
So.... you have shown performance problem in one driver. Maybe *bad*
performance problem, but only performance problem. There may be other
performance problems out there. And what?
Pavel
--
When do you have heart between your knees?
On Sunday den 27 January 2002 21.52, Pavel Machek wrote:
> Hi!
>
> > > testing the patch complaining about, AND one that seems like it could
> > > be addressed by using IRQ disabling as a latency guard in addition to
> > > spinlocks.
> >
> > I dont believe anyone has tested the driver hard with pre-empt. Its not
> > that this driver can't be fixed. Its that this is one tiny example of
> > maybe thousands of other similar flaws lurking. There is no obvious
> > automated way to find them either.
>
> So.... you have shown performance problem in one driver. Maybe *bad*
> performance problem, but only performance problem. There may be other
> performance problems out there. And what?
> Pavel
In Alans example it is not a performance problem - it is more of a
correctness problem.
The case when a driver were disabling a specific interrupt was not handled
in a 100% correct way.
There are some other cases that might be even harder to detect - disabling
from a device by writing in its control register.
But if the preempt patch is added those critical sections can be protected.
It is not trivial nor impossible...
/RogerL
--
Roger Larsson
Skellefte?
Sweden