Op 15-10-12 20:40, Thomas Hellstrom schreef:
> On 10/15/2012 05:37 PM, Maarten Lankhorst wrote:
>> Op 15-10-12 14:27, Thomas Hellstrom schreef:
>>> On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
Op 12-10-12 07:57, Thomas Hellstrom schreef:
> On 10/11/2012 10:55 PM, Maarten Lankhorst wrot
On 10/15/2012 05:37 PM, Maarten Lankhorst wrote:
> Op 15-10-12 14:27, Thomas Hellstrom schreef:
>> On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
>>> Op 12-10-12 07:57, Thomas Hellstrom schreef:
On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
> Op 11-10-12 21:26, Thomas Hellstrom schree
Op 15-10-12 17:37, Maarten Lankhorst schreef:
>>> To make multi-object reservation work, the fix is to add a ticket "lock" of
>>> which all the
>>> reservation objects are a nested lock of. Since in this case the ticket
>>> lock would prevent
>>> deadlocks, this is acceptable. Having 2 ticket 'l
Op 15-10-12 14:27, Thomas Hellstrom schreef:
> On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
>> Op 12-10-12 07:57, Thomas Hellstrom schreef:
>>> On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
Op 11-10-12 21:26, Thomas Hellstrom schreef:
> On 10/11/2012 08:42 PM, Maarten Lankhorst wrot
On Mon, Oct 15, 2012 at 08:34:17PM +0200, Maarten Lankhorst wrote:
> Op 15-10-12 17:37, Maarten Lankhorst schreef:
> >>> To make multi-object reservation work, the fix is to add a ticket "lock"
> >>> of which all the
> >>> reservation objects are a nested lock of. Since in this case the ticket
>
On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
> Op 12-10-12 07:57, Thomas Hellstrom schreef:
>> On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
>>> Op 11-10-12 21:26, Thomas Hellstrom schreef:
On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
>> Anyway, if you plan to remove the fe
On 10/12/2012 09:49 AM, Maarten Lankhorst wrote:
>
> I suppose there will stay a small race though,
Hmm, where?
>>> When you enter the ddestroy path, you drop the lock and hope the buffer
>>> doesn't reserved
>>> away from under you.
>> Yes, that code isn't fully correct, it's missing a c
On Mon, Oct 15, 2012 at 08:34:17PM +0200, Maarten Lankhorst wrote:
> Op 15-10-12 17:37, Maarten Lankhorst schreef:
> >>> To make multi-object reservation work, the fix is to add a ticket "lock"
> >>> of which all the
> >>> reservation objects are a nested lock of. Since in this case the ticket
>
Op 15-10-12 20:40, Thomas Hellstrom schreef:
> On 10/15/2012 05:37 PM, Maarten Lankhorst wrote:
>> Op 15-10-12 14:27, Thomas Hellstrom schreef:
>>> On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
Op 12-10-12 07:57, Thomas Hellstrom schreef:
> On 10/11/2012 10:55 PM, Maarten Lankhorst wrot
On 10/15/2012 05:37 PM, Maarten Lankhorst wrote:
Op 15-10-12 14:27, Thomas Hellstrom schreef:
On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
Op 12-10-12 07:57, Thomas Hellstrom schreef:
On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
Op 11-10-12 21:26, Thomas Hellstrom schreef:
On 10/11/2
Op 15-10-12 17:37, Maarten Lankhorst schreef:
>>> To make multi-object reservation work, the fix is to add a ticket "lock" of
>>> which all the
>>> reservation objects are a nested lock of. Since in this case the ticket
>>> lock would prevent
>>> deadlocks, this is acceptable. Having 2 ticket 'l
Op 15-10-12 14:27, Thomas Hellstrom schreef:
> On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
>> Op 12-10-12 07:57, Thomas Hellstrom schreef:
>>> On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
Op 11-10-12 21:26, Thomas Hellstrom schreef:
> On 10/11/2012 08:42 PM, Maarten Lankhorst wrot
On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
Op 12-10-12 07:57, Thomas Hellstrom schreef:
On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
Op 11-10-12 21:26, Thomas Hellstrom schreef:
On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
Anyway, if you plan to remove the fence lock and protec
On 10/12/2012 09:49 AM, Maarten Lankhorst wrote:
I suppose there will stay a small race though,
Hmm, where?
When you enter the ddestroy path, you drop the lock and hope the buffer doesn't
reserved
away from under you.
Yes, that code isn't fully correct, it's missing a check for still on dde
Op 12-10-12 07:57, Thomas Hellstrom schreef:
> On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
>> Op 11-10-12 21:26, Thomas Hellstrom schreef:
>>> On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
>>>
> Anyway, if you plan to remove the fence lock and protect it with reserve,
> you must
>>
Op 12-10-12 07:57, Thomas Hellstrom schreef:
> On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
>> Op 11-10-12 21:26, Thomas Hellstrom schreef:
>>> On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
>>>
> Anyway, if you plan to remove the fence lock and protect it with reserve,
> you must
>>
On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
> Op 11-10-12 21:26, Thomas Hellstrom schreef:
>> On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
>>
Anyway, if you plan to remove the fence lock and protect it with reserve,
you must
make sure that a waiting reserve is never done in
Op 12-10-12 07:57, Thomas Hellstrom schreef:
> On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
>> Op 11-10-12 21:26, Thomas Hellstrom schreef:
>>> On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
>>>
> Anyway, if you plan to remove the fence lock and protect it with reserve,
> you must
>>
Op 12-10-12 07:57, Thomas Hellstrom schreef:
> On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
>> Op 11-10-12 21:26, Thomas Hellstrom schreef:
>>> On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
>>>
> Anyway, if you plan to remove the fence lock and protect it with reserve,
> you must
>>
On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
Op 11-10-12 21:26, Thomas Hellstrom schreef:
On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
Anyway, if you plan to remove the fence lock and protect it with reserve, you
must
make sure that a waiting reserve is never done in a destruction pat
Op 11-10-12 21:26, Thomas Hellstrom schreef:
> On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
>
>>
>>> Anyway, if you plan to remove the fence lock and protect it with reserve,
>>> you must
>>> make sure that a waiting reserve is never done in a destruction path. I
>>> think this
>>> mostly con
On 10/11/2012 09:26 PM, Thomas Hellstrom wrote:
> On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
> I can't see how the waiting reserve in ttm_bo_cleanup_refs would cause
> a deadlock,
> because the buffer about to be reserved is always *last* in a
> reservation sequence, and the
> reservation
On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
>
>> Anyway, if you plan to remove the fence lock and protect it with reserve,
>> you must
>> make sure that a waiting reserve is never done in a destruction path. I
>> think this
>> mostly concerns the nvidia driver.
> Well I don't think any lock
Op 11-10-12 18:57, Thomas Hellstrom schreef:
> On 10/11/2012 04:50 PM, Maarten Lankhorst wrote:
>> I was trying to clean ttm up a little so my changes would be less invasive,
>> and simplify
>> the code for debuggability. During testing I noticed the following
>> weirdnesses:
>> - ttm_mem_evict_f
On 10/11/2012 04:50 PM, Maarten Lankhorst wrote:
> I was trying to clean ttm up a little so my changes would be less invasive,
> and simplify
> the code for debuggability. During testing I noticed the following
> weirdnesses:
> - ttm_mem_evict_first ignores no_wait_gpu if the buffer is on the dde
I was trying to clean ttm up a little so my changes would be less invasive, and
simplify
the code for debuggability. During testing I noticed the following weirdnesses:
- ttm_mem_evict_first ignores no_wait_gpu if the buffer is on the ddestroy list.
If you follow the code, it will effectively sp
Op 11-10-12 21:26, Thomas Hellstrom schreef:
> On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
>
>>
>>> Anyway, if you plan to remove the fence lock and protect it with reserve,
>>> you must
>>> make sure that a waiting reserve is never done in a destruction path. I
>>> think this
>>> mostly con
On 10/11/2012 09:26 PM, Thomas Hellstrom wrote:
On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
I can't see how the waiting reserve in ttm_bo_cleanup_refs would cause
a deadlock,
because the buffer about to be reserved is always *last* in a
reservation sequence, and the
reservation is always
On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
Anyway, if you plan to remove the fence lock and protect it with reserve, you
must
make sure that a waiting reserve is never done in a destruction path. I think
this
mostly concerns the nvidia driver.
Well I don't think any lock should ever b
Op 11-10-12 18:57, Thomas Hellstrom schreef:
> On 10/11/2012 04:50 PM, Maarten Lankhorst wrote:
>> I was trying to clean ttm up a little so my changes would be less invasive,
>> and simplify
>> the code for debuggability. During testing I noticed the following
>> weirdnesses:
>> - ttm_mem_evict_f
On 10/11/2012 04:50 PM, Maarten Lankhorst wrote:
I was trying to clean ttm up a little so my changes would be less invasive, and
simplify
the code for debuggability. During testing I noticed the following weirdnesses:
- ttm_mem_evict_first ignores no_wait_gpu if the buffer is on the ddestroy lis
I was trying to clean ttm up a little so my changes would be less invasive, and
simplify
the code for debuggability. During testing I noticed the following weirdnesses:
- ttm_mem_evict_first ignores no_wait_gpu if the buffer is on the ddestroy list.
If you follow the code, it will effectively sp
32 matches
Mail list logo
