On Tue, Jan 12, 2016 at 12:54:25PM +0000, Tvrtko Ursulin wrote: > > On 12/01/16 12:12, Chris Wilson wrote: > >On Tue, Jan 12, 2016 at 11:56:11AM +0000, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > >> > >>LRC lifetime is well defined so we can cache the page pointing > >>to the object backing store in the context in order to avoid > >>walking over the object SG page list from the interrupt context > >>without the big lock held. > >> > >>v2: Also cache the mapping. (Chris Wilson) > >>v3: Unmap on the error path. > > > >Then we only use the lrc_state_page in the unmapping, hardly worth the > >cost of saving it. > > Ok. > > Do you also know if this would now require any flushing or something > if previously kunmap_atomic might have done something under the > covers? kmap_atomic only changes the PTE and the unmap would flush the TLB. In terms of our pointer access, using kmap/kmap_atomic is equivalent. (Just kmap_atomic is meant to be cheaper to set up and a limited resource which can only be used without preemption.) > >The reg_state is better associated with the ring (since it basically > >contains the analog of the RING_HEAD and friends). > > Hm, not sure. The page belongs to the object from that anonymous > struct in intel_context so I think it is best to keep them together. The page does sure, but the state does not. The result is that we get: ring->registers[CTX_RING_BUFFER_STATE+1] = ring->vma->node.state; ASSIGN_CTX_PDP(ppgtt, ring->registers, 3); ASSIGN_CTX_PDP(ppgtt, ring->registers, 2); ASSIGN_CTX_PDP(ppgtt, ring->registers, 1); ASSIGN_CTX_PDP(ppgtt, ring->registers, 0); ring->registers[CTX_RING_TAIL+1] = req->tail; which makes a lot more sense, to me, when viewed against the underlying architecture of the hardware and comparing against the legacy ringbuffer. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
