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

Daniel Vetter daniel at ffwll.ch
Mon Sep 28 01:54:59 PDT 2015


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


More information about the Intel-gfx mailing list