On Wed, Sep 23, 2015 at 05:54:25PM +0100, Chris Wilson wrote: > On Wed, Sep 23, 2015 at 12:52:23PM -0300, Paulo Zanoni wrote: > > Technology has evolved and now we have eDP panels with 3200x1800 > > resolution. In the meantime, the BIOS guys didn't change the default > > 32mb for stolen memory. On top of that, we can't assume our users will > > be able to increase the default stolen memory size to more than 32mb - > > I'm not even sure all BIOSes allow that. > > fbcon is just a small part of the problem, we can trivially fill stolen > with kernel objects even before we let userspace at it. I agree that being > able to prioritise allocation to HW functions is good, but it is not that hard > to write an eviction + migration pass - given that we already have large > chunks of that written. The only issue is that (at least the sketch I > have in mind) will only evict objects so if we have fragmentation > caused by HW functions, allocations can still fail. Problem with fbcon is that we can migrate it (well we could do _really_ crazy stuff with a vmalloc are, but that seems pointless). So I think we still need this hack no matter what. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
