On Tue, Sep 23, 2014 at 10:26:26AM +0200, Daniel Vetter wrote: > On Fri, Sep 19, 2014 at 09:00:00PM +0100, Chris Wilson wrote: > > On Fri, Sep 19, 2014 at 06:21:46PM +0000, Tian, Kevin wrote: > > > > From: Chris Wilson > > > > The implementation also looks backwards. To work correctly with the GTT > > > > allocator, you need to preallocate the reserved space such that it can > > > > only allocate from the allowed ranges. Similarly, it should evict any > > > > conflicting nodes when deballooning. > > > > > > Could you elaborate a bit for above suggestion? > > > > My expectation was that the dev_priv->gtt.base.vm would contain exactly > > two holes after setup (in the mappable and non-mappable range). To do > > that you would explicitly reserve everything barred from this client > > using a set of drm_mm_reserve_node() > > Essentially a reserve_node implements what you open-code with > insert_node_range right now. Heh, there is a big difference. One inserts exactly where you ask and fails if it conflicts, the other inserts where it feels like within that range. > One issue aside with both this and with the PDE reservations for gen7 is > that there are now other thins in the ggtt drm_mm allocator than just gem > objects. Which means our debugfs files are now less useful. > > It might be useful to augment that dumper with one that dumps everything. > We could add a few bits of driver-private tags in drm_mm_node (there's > space) to figure out what kind of object it is. Would be a great follow-up > task. I think moving the other way and making them all objects so that we can tie them into evection and the shrinker, use more interesting allocation strategies, improve integration with debugging etc. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
