On 04/10/2014 01:08 PM, Thomas Hellstrom wrote: > On 04/10/2014 12:07 PM, Maarten Lankhorst wrote: >> Hey, >> >> op 10-04-14 10:46, Thomas Hellstrom schreef: >>> Hi! >>> >>> Ugh. This became more complicated than I thought, but I'm OK with moving >>> TTM over to fence while we sort out >>> how / if we're going to use this. >>> >>> While reviewing, it struck me that this is kind of error-prone, and hard >>> to follow since we're operating on a structure that may be >>> continually updated under us, needing a lot of RCU-specific macros and >>> barriers. >> Yeah, but with the exception of dma_buf_poll I don't think there is >> anything else >> outside drivers/base/reservation.c has to deal with rcu. >> >>> Also the rcu wait appears to not complete until there are no busy fences >>> left (new ones can be added while we wait) rather than >>> waiting on a snapshot of busy fences. >> This has been by design, because 'wait for bo idle' type of functions >> only care >> if the bo is completely idle or not. > No, not when using RCU, because the bo may be busy again before the > function returns :) > Complete idleness can only be guaranteed if holding the reservation, or > otherwise making sure > that no new rendering is submitted to the buffer, so it's an overkill to > wait for complete idleness here. > Although, if we fail to get a refcount for a fence, and it's still busy we need to do a seq retry, because the fence might have been replaced by another fence from the same context, without being idle. That check is not present in the snapshot code I sent. /Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
