[PATCH 4/4] drm/ttm: Optimize reservation slightly

2012-11-06 Thread Thomas Hellstrom
Reservation locking currently always takes place under the LRU spinlock. Hence, strictly there is no need for an atomic_cmpxchg call; we can use atomic_read followed by atomic_write since nobody else will ever reserve without the lru spinlock held. At least on Intel this should remove a locked bus

[PATCH 4/4] drm/ttm: Optimize reservation slightly

2012-11-06 Thread Thomas Hellstrom
Reservation locking currently always takes place under the LRU spinlock. Hence, strictly there is no need for an atomic_cmpxchg call; we can use atomic_read followed by atomic_write since nobody else will ever reserve without the lru spinlock held. At least on Intel this should remove a locked bus

[PATCH 4/4] drm/ttm: Optimize reservation slightly

2012-11-05 Thread Thomas Hellstrom
On 11/05/2012 03:01 PM, Maarten Lankhorst wrote: > Hey, > > Op 05-11-12 14:31, Thomas Hellstrom schreef: >> Reservation locking currently always takes place under the LRU spinlock. >> Hence, strictly there is no need for an atomic_cmpxchg call; we can use >> atomic_read followed by atomic_write sin

[PATCH 4/4] drm/ttm: Optimize reservation slightly

2012-11-05 Thread Maarten Lankhorst
Hey, Op 05-11-12 14:31, Thomas Hellstrom schreef: > Reservation locking currently always takes place under the LRU spinlock. > Hence, strictly there is no need for an atomic_cmpxchg call; we can use > atomic_read followed by atomic_write since nobody else will ever reserve > without the lru spinlo

[PATCH 4/4] drm/ttm: Optimize reservation slightly

2012-11-05 Thread Thomas Hellstrom
Reservation locking currently always takes place under the LRU spinlock. Hence, strictly there is no need for an atomic_cmpxchg call; we can use atomic_read followed by atomic_write since nobody else will ever reserve without the lru spinlock held. At least on Intel this should remove a locked bus

[PATCH 4/4] drm/ttm: Optimize reservation slightly

2012-11-05 Thread Thomas Hellstrom
Reservation locking currently always takes place under the LRU spinlock. Hence, strictly there is no need for an atomic_cmpxchg call; we can use atomic_read followed by atomic_write since nobody else will ever reserve without the lru spinlock held. At least on Intel this should remove a locked bus

Re: [PATCH 4/4] drm/ttm: Optimize reservation slightly

2012-11-05 Thread Thomas Hellstrom
On 11/05/2012 03:01 PM, Maarten Lankhorst wrote: Hey, Op 05-11-12 14:31, Thomas Hellstrom schreef: Reservation locking currently always takes place under the LRU spinlock. Hence, strictly there is no need for an atomic_cmpxchg call; we can use atomic_read followed by atomic_write since nobody e

Re: [PATCH 4/4] drm/ttm: Optimize reservation slightly

2012-11-05 Thread Maarten Lankhorst
Hey, Op 05-11-12 14:31, Thomas Hellstrom schreef: > Reservation locking currently always takes place under the LRU spinlock. > Hence, strictly there is no need for an atomic_cmpxchg call; we can use > atomic_read followed by atomic_write since nobody else will ever reserve > without the lru spinlo

[PATCH 4/4] drm/ttm: Optimize reservation slightly

2012-11-05 Thread Thomas Hellstrom
Reservation locking currently always takes place under the LRU spinlock. Hence, strictly there is no need for an atomic_cmpxchg call; we can use atomic_read followed by atomic_write since nobody else will ever reserve without the lru spinlock held. At least on Intel this should remove a locked bus

[PATCH 4/4] drm/ttm: Optimize reservation slightly

2012-11-05 Thread Thomas Hellstrom
Reservation locking currently always takes place under the LRU spinlock. Hence, strictly there is no need for an atomic_cmpxchg call; we can use atomic_read followed by atomic_write since nobody else will ever reserve without the lru spinlock held. At least on Intel this should remove a locked bus