On Wed, Sep 24, 2014 at 08:35:50PM +0800, Zhang, Yu wrote: > Hi Daniel & Chris, > > Thank you very much for your comments, And sorry for my late > reply.:) I was focusing on other tasks previously. > See my questions below: > > On 9/23/2014 7:25 PM, Daniel Vetter wrote: > >On Tue, Sep 23, 2014 at 10:19:02AM +0100, Chris Wilson wrote: > >>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. > > Do you mean drm_mm_search_free_in_range_generic() may not get > reserve the exact range we are expecting to? Is this why you'd > prefer the drm_mm_reserve_node()? > > Besides, the ggtt_vm->mm is just initialized right before the > ballooning code in routine i915_gem_setup_global_gtt(), so is there > any chance the range to be partitioned out is already reserved by > someone else? No. It is just that drm_mm_reserve_node() was added to have the precise semantics expected here with the strict checks. And should work better with dynamic ballooning... -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
