linux-2.5.18: DRM + cmpxchg issues
Adam,
I expect the answer is that we need to dig out the old one.
Previously I don't think the full cmpxchg semantics werere required unless the box is smp -- there's no case where atomic operations are required for hardware interaction, for example. ...
Probably this changed with preempt, though, so we need one even on UP boxes...
Keith
Quoted 11 lines · Keith Whitwell
Adam,
I expect the answer is that we need to dig out the old one.
Previously I don't think the full cmpxchg semantics werere required unless the box is smp -- there's no case where atomic operations are required for hardware interaction, for example. ...
Probably this changed with preempt, though, so we need one even on UP boxes...
I can not think of any reason to need a lock or atomic operation because of preempt. Even the management of the preempt on/off flags at most requires memory barriers, even in SMP boxen. Do you have an example?
Signature · 6 lines
George Anzinger [email protected] High-res-timers: http://sourceforge.net/projects/high-res-timers/ Real time sched: http://sourceforge.net/projects/rtsched/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
Quoted 10 lines · george anzinger
Quoted 8 lines · Keith Whitwell
Adam,
I expect the answer is that we need to dig out the old one.
Previously I don't think the full cmpxchg semantics werere required unless the box is smp -- there's no case where atomic operations are required for hardware interaction, for example. ...
Quoted 7 lines
Quoted 3 lines
Probably this changed with preempt, though, so we need one even on UP boxes...
I can not think of any reason to need a lock or atomic operation because of preempt. Even the management of the preempt on/off flags at most requires memory barriers, even in SMP boxen. Do you have an example?
No, I was just pointing out grey areas in my own knowledge.
Keith