[Intel-gfx] [PATCH 3/7] drm/i915: don't allocate fbcon from stolen memory if it's too big

[Daniel Vetter]

On Mon, Sep 28, 2015 at 10:09:18AM +0100, Chris Wilson wrote:
> On Mon, Sep 28, 2015 at 10:54:59AM +0200, Daniel Vetter wrote:
> > 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_
> 
> Can or can't? The screen.base pointer is an iomap so to migrate it we
> just need to point the PTE elsewhere. We can't combine a vmalloc arena
> and stolen anyway :|

I meant can't. And the vma thing would have been to virtualize the gtt
offset so that we can move that one around (I was too lazy to look up).
But since we could exchange the gtt ptes that's not actually required, I
mixed that up with evicting fbcon from gtt.

In short I made a mess ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch