Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

2016-10-17 Thread Chris Wilson
On Mon, Oct 17, 2016 at 10:47:09AM +0100, Tvrtko Ursulin wrote: > > On 14/10/2016 15:42, Chris Wilson wrote: > >On Fri, Oct 14, 2016 at 03:35:59PM +0100, Tvrtko Ursulin wrote: > >>On 14/10/2016 14:53, Chris Wilson wrote: > >We do pass NORETRY | NOWARN for the higher order allocations, so it >

Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

2016-10-17 Thread Tvrtko Ursulin
On 14/10/2016 15:42, Chris Wilson wrote: On Fri, Oct 14, 2016 at 03:35:59PM +0100, Tvrtko Ursulin wrote: On 14/10/2016 14:53, Chris Wilson wrote: We do pass NORETRY | NOWARN for the higher order allocations, so it shouldn't be as bad it seems? I don't know for sure without looking into the

Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

2016-10-14 Thread Chris Wilson
On Fri, Oct 14, 2016 at 03:35:59PM +0100, Tvrtko Ursulin wrote: > > On 14/10/2016 14:53, Chris Wilson wrote: > >>>We do pass NORETRY | NOWARN for the higher order allocations, so it > >>>shouldn't be as bad it seems? > >>I don't know for sure without looking into the implementation > >>details.

Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

2016-10-14 Thread Tvrtko Ursulin
On 14/10/2016 14:53, Chris Wilson wrote: On Fri, Oct 14, 2016 at 02:44:00PM +0100, Tvrtko Ursulin wrote: On 14/10/2016 13:54, Chris Wilson wrote: On Fri, Oct 14, 2016 at 01:42:35PM +0100, Tvrtko Ursulin wrote: On 14/10/2016 13:18, Chris Wilson wrote: + gfp = GFP_KERNEL | __GFP_HIGHMEM

Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

2016-10-14 Thread Chris Wilson
On Fri, Oct 14, 2016 at 02:44:00PM +0100, Tvrtko Ursulin wrote: > > On 14/10/2016 13:54, Chris Wilson wrote: > >On Fri, Oct 14, 2016 at 01:42:35PM +0100, Tvrtko Ursulin wrote: > >>On 14/10/2016 13:18, Chris Wilson wrote: > >>>+ gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE; > >>>+ if

Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

2016-10-14 Thread Tvrtko Ursulin
On 14/10/2016 13:54, Chris Wilson wrote: On Fri, Oct 14, 2016 at 01:42:35PM +0100, Tvrtko Ursulin wrote: On 14/10/2016 13:18, Chris Wilson wrote: + gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE; + if (IS_CRESTLINE(i915) || IS_BROADWATER(i915)) { + /* 965gm

Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

2016-10-14 Thread Chris Wilson
On Fri, Oct 14, 2016 at 01:42:35PM +0100, Tvrtko Ursulin wrote: > > On 14/10/2016 13:18, Chris Wilson wrote: > >+gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE; > >+if (IS_CRESTLINE(i915) || IS_BROADWATER(i915)) { > >+/* 965gm cannot relocate objects above 4GiB. */ > >+

Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

2016-10-14 Thread Tvrtko Ursulin
On 14/10/2016 13:18, Chris Wilson wrote: Quite a few of our objects used for internal hardware programming do not benefit from being swappable or from being zero initialised. As such they do not benefit from using a shmemfs backing storage and since they are internal and never directly exposed

[Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

2016-10-14 Thread Chris Wilson
Quite a few of our objects used for internal hardware programming do not benefit from being swappable or from being zero initialised. As such they do not benefit from using a shmemfs backing storage and since they are internal and never directly exposed to the user, we do not need to worry about