On 04/26/2014 06:10 AM, Chris Wilson wrote:
>>> > > Thanks for the pointer to
>>> > > register_oom_notifier(), I can use that to make sure that we do purge
>>> > > everything from the GPU, and do a sanity check at the same time, before
>>> > > we start killing processes.
>> >
>> > Actually, that o
On Fri, Apr 25, 2014 at 10:18:57AM -0700, Dave Hansen wrote:
> On 04/25/2014 12:23 AM, Chris Wilson wrote:
> > On Thu, Apr 24, 2014 at 03:35:47PM -0700, Dave Hansen wrote:
> >> On 04/24/2014 08:39 AM, Chris Wilson wrote:
> >>> On Thu, Apr 24, 2014 at 08:21:58AM -0700, Dave Hansen wrote:
> Is i
Poking around with those tracepoints, I don't see the i915 shrinker
getting run, only i915_gem_inactive_count() being called. It must be
returning 0 because we're never even _getting_ to the tracepoints
themselves after calling i915_gem_inactive_count().
This is on my laptop, and I haven't been a
On 04/25/2014 12:23 AM, Chris Wilson wrote:
> On Thu, Apr 24, 2014 at 03:35:47PM -0700, Dave Hansen wrote:
>> On 04/24/2014 08:39 AM, Chris Wilson wrote:
>>> On Thu, Apr 24, 2014 at 08:21:58AM -0700, Dave Hansen wrote:
Is it possible that there's still a get_page() reference that's holding
>>>
On Thu, Apr 24, 2014 at 03:35:47PM -0700, Dave Hansen wrote:
> On 04/24/2014 08:39 AM, Chris Wilson wrote:
> > On Thu, Apr 24, 2014 at 08:21:58AM -0700, Dave Hansen wrote:
> >> Is it possible that there's still a get_page() reference that's holding
> >> those pages in place from the graphics code?
On 04/24/2014 08:39 AM, Chris Wilson wrote:
> On Thu, Apr 24, 2014 at 08:21:58AM -0700, Dave Hansen wrote:
>> Is it possible that there's still a get_page() reference that's holding
>> those pages in place from the graphics code?
>
> Not from i915.ko. The last resort of our shrinker is to drop all
On Thu, Apr 24, 2014 at 08:21:58AM -0700, Dave Hansen wrote:
> On 04/23/2014 10:58 PM, Chris Wilson wrote:
> > [ 4756.750938] Node 0 DMA free:14664kB min:32kB low:40kB high:48kB
> > active_anon:0kB inactive_anon:1024kB active_file:0kB inactive_file:4kB
> > unevictable:0kB isolated(anon):0kB isola
On 04/23/2014 10:58 PM, Chris Wilson wrote:
> [ 4756.750938] Node 0 DMA free:14664kB min:32kB low:40kB high:48kB
> active_anon:0kB inactive_anon:1024kB active_file:0kB inactive_file:4kB
> unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB
> managed:15908kB mlocked:0kB dirty:0k
On Wed, Apr 23, 2014 at 02:14:36PM -0700, Dave Hansen wrote:
> On 04/22/2014 12:30 PM, Daniel Vetter wrote:
> >> > > During testing of i915.ko with working texture sets larger than RAM, we
> >> > > encounter OOM with plenty of memory still trapped within writeback,
> >> > > e.g:
> >> > >
> >> > >
On 04/22/2014 12:30 PM, Daniel Vetter wrote:
>> > > During testing of i915.ko with working texture sets larger than RAM, we
>> > > encounter OOM with plenty of memory still trapped within writeback, e.g:
>> > >
>> > > [ 42.386039] active_anon:10134 inactive_anon:1900781 isolated_anon:32
>> > >
On Fri, Apr 18, 2014 at 12:14:16PM -0700, Andrew Morton wrote:
> On Thu, 10 Apr 2014 08:05:06 +0100 Chris Wilson
> wrote:
>
> > During testing of i915.ko with working texture sets larger than RAM, we
> > encounter OOM with plenty of memory still trapped within writeback, e.g:
> >
> > [ 42.386
On Thu, 10 Apr 2014 08:05:06 +0100 Chris Wilson
wrote:
> During testing of i915.ko with working texture sets larger than RAM, we
> encounter OOM with plenty of memory still trapped within writeback, e.g:
>
> [ 42.386039] active_anon:10134 inactive_anon:1900781 isolated_anon:32
> active_file:
12 matches
Mail list logo