> This is for the DMA-buf mapping function, not the normal driver mmap implementation. So we can be pretty sure that the memory will be CPU accessed. > > The question in my mind is if it really is such a good idea to ping/pong the page when the GPU/CPU is accessing them. Not that I want to block this patch, but that is usually something we try to avoid. Between mmap and cpu access, there could be other operations, so we only migrate once when cpu when CPU read is requested. Sam On 2017-12-14 12:27 PM, Christian König wrote: > Am 14.12.2017 um 17:16 schrieb Michel Dänzer: >> On 2017-12-14 09:07 AM, Christian König wrote: >>> Please CC Michel as well, >> No need, I read the lists (just sometimes get a little swamped and take >> time to catch up). >> >> >>> he originally commented that we should try to solve this in the DDX instead. >> I don't think a DDX driver is even involved in the scenario Sam's >> working on. >> >> Do you mean that the BO should be created in GTT in the first place if >> possible? > > Yes, well as far as I understood that's what you suggested. > >>  I did suggest that before, but I'm not sure it's feasible in >> this scenario. > > I agree, not the slightest idea how the user space app created the BO in the first place. > >> >> >>> And BTW: Why don't we just do the migration during the mmap call? >> At mmap time, we don't know when the BO will actually be accessed by the >> CPU (or indeed whether at all). If we do the migration at that point, >> there's no guarantee that the BO will still be in GTT when it's accessed >> by the CPU. > > This is for the DMA-buf mapping function, not the normal driver mmap implementation. So we can be pretty sure that the memory will be CPU accessed. > > The question in my mind is if it really is such a good idea to ping/pong the page when the GPU/CPU is accessing them. Not that I want to block this patch, but that is usually something we try to avoid. > > Regards, > Christian.
