On Sun, 2 Aug 2020 at 04:29, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > Our timeline lock is our defence against a concurrent execbuf > interrupting our request construction. we need hold it throughout or, > for example, a second thread may interject a relocation request in > between our own relocation request and execution in the ring. > > A second, major benefit, is that it allows us to preserve a large chunk > of the ringbuffer for our exclusive use; which should virtually > eliminate the threat of hitting a wait_for_space during request > construction -- although we should have already dropped other > contentious locks at that point. When I first came here, this was all swamp. Everyone said I was daft to build a castle on a swamp, but I built it all the same, just to show them. It sank into the swamp. So I built a second one. And that one sank into the swamp. So I built a third. That burned down, fell over, and then sank into the swamp. But the fourth one stayed up. And that’s what you’re going to get, Son, the strongest castle in all of England. This patch makes me feel we are somewhere between the second castle and the burning down. Dave. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
