Am 12.02.2018 um 17:57 schrieb Felix Kuehling: >> [SNIP] >> I see that as an advantage rather than a problem, cause it fixes a >> couple of problems with the KFD where the address space of the inode >> is not managed correctly as far as I can see. > I don't think GEM is involved in the management of address space. That's > handled inside TTM and drm_vma_manager, both of which we are using. We > have tested CPU mappings with evictions and this is working correctly now. Ok, correct. I was thinking about that as one large functionality. When you see it like this GEM basically only implements looking up BOs and reference counting them, but both are still useful features. > We had problems with this before, when we were CPU-mapping our buffers > through the KFD device FD. > >> That implementation issues never caused problems right now because you >> never tried to unmap doorbells. But with the new eviction code that is >> about to change, isn't it? > I don't understand this comment. What does this have to do with doorbells? I was assuming that doorbells are now unmapped to figure out when to start a process again. See what I'm missing is how does userspace figures out which address to use to map the doorbell? E.g. I don't see a call to drm_vma_offset_manager_init() or something like that. > Doorbells are never unmapped. When queues are evicted doorbells remain > mapped to the process. User mode can continue writing to doorbells, > though they won't have any immediate effect while the corresponding > queues are unmapped from the HQDs. Do you simply assume that after evicting a process it always needs to be restarted without checking if it actually does something? Or how does that work? Regards, Christian.
