Re: [Intel-gfx] [PATCH v4 17/31] drivers: convert shrinkers to new count/scan API
Sorry for the following crappy message. I came travelling without my laptop.
Please note that one of my patches implement one shot shrinkers onto of
vmpressure mechanism. It can still be called frequently, because right now it
is called every time userspace would get an event. But at least it won't
iterate.
You can try investigating if that interface suits your i915 needs better
Sent by Samsung Mobile
Original message
From: Mel Gorman
Date:
To: Kent Overstreet
Cc: Glauber Costa
,linux...@kvack.org,cgro...@vger.kernel.org,Andrew Morton
,Greg Thelen
,kamezawa.hir...@jp.fujitsu.com,Michal Hocko
,Johannes Weiner ,Dave Chinner
,intel-gfx@lists.freedesktop.org,dri-de...@lists.freedesktop.org,de...@driverdev.osuosl.org,Dan
Magenheimer
Subject: Re: [PATCH v4 17/31] drivers: convert shrinkers to new count/scan API
On Tue, Apr 30, 2013 at 03:00:50PM -0700, Kent Overstreet wrote:
> On Tue, Apr 30, 2013 at 10:53:55PM +0100, Mel Gorman wrote:
> > On Sat, Apr 27, 2013 at 03:19:13AM +0400, Glauber Costa wrote:
> > > diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c
> > > index 03e44c1..8b9c1a6 100644
> > > --- a/drivers/md/bcache/btree.c
> > > +++ b/drivers/md/bcache/btree.c
> > > @@ -599,11 +599,12 @@ static int mca_reap(struct btree *b, struct closure
> > > *cl, unsigned min_order)
> > >return 0;
> > > }
> > >
> > > -static int bch_mca_shrink(struct shrinker *shrink, struct shrink_control
> > > *sc)
> > > +static long bch_mca_scan(struct shrinker *shrink, struct shrink_control
> > > *sc)
> > > {
> > >struct cache_set *c = container_of(shrink, struct cache_set, shrink);
> > >struct btree *b, *t;
> > >unsigned long i, nr = sc->nr_to_scan;
> > > + long freed = 0;
> > >
> > >if (c->shrinker_disabled)
> > >return 0;
> >
> > -1 if shrinker disabled?
> >
> > Otherwise if the shrinker is disabled we ultimately hit this loop in
> > shrink_slab_one()
>
> My memory is very hazy on this stuff, but I recall there being another
> loop that'd just spin if we always returned -1.
>
> (It might've been /proc/sys/vm/drop_caches, or maybe that was another
> bug..)
>
It might be worth chasing down what that bug was and fixing it.
> But 0 should certainly be safe - if we're always returning 0, then we're
> claiming we don't have anything to shrink.
>
It won't crash, but in Glauber's current code, it'll call you a few more
times uselessly and the scanned statistics become misleading. I think
Glauber/Dave's series is a big improvement over what we currently have
and it would be nice to get it ironed out.
--
Mel Gorman
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 17/31] drivers: convert shrinkers to new count/scan API
On Tue, Apr 30, 2013 at 03:00:50PM -0700, Kent Overstreet wrote:
> On Tue, Apr 30, 2013 at 10:53:55PM +0100, Mel Gorman wrote:
> > On Sat, Apr 27, 2013 at 03:19:13AM +0400, Glauber Costa wrote:
> > > diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c
> > > index 03e44c1..8b9c1a6 100644
> > > --- a/drivers/md/bcache/btree.c
> > > +++ b/drivers/md/bcache/btree.c
> > > @@ -599,11 +599,12 @@ static int mca_reap(struct btree *b, struct closure
> > > *cl, unsigned min_order)
> > > return 0;
> > > }
> > >
> > > -static int bch_mca_shrink(struct shrinker *shrink, struct shrink_control
> > > *sc)
> > > +static long bch_mca_scan(struct shrinker *shrink, struct shrink_control
> > > *sc)
> > > {
> > > struct cache_set *c = container_of(shrink, struct cache_set, shrink);
> > > struct btree *b, *t;
> > > unsigned long i, nr = sc->nr_to_scan;
> > > + long freed = 0;
> > >
> > > if (c->shrinker_disabled)
> > > return 0;
> >
> > -1 if shrinker disabled?
> >
> > Otherwise if the shrinker is disabled we ultimately hit this loop in
> > shrink_slab_one()
>
> My memory is very hazy on this stuff, but I recall there being another
> loop that'd just spin if we always returned -1.
>
> (It might've been /proc/sys/vm/drop_caches, or maybe that was another
> bug..)
>
It might be worth chasing down what that bug was and fixing it.
> But 0 should certainly be safe - if we're always returning 0, then we're
> claiming we don't have anything to shrink.
>
It won't crash, but in Glauber's current code, it'll call you a few more
times uselessly and the scanned statistics become misleading. I think
Glauber/Dave's series is a big improvement over what we currently have
and it would be nice to get it ironed out.
--
Mel Gorman
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 17/31] drivers: convert shrinkers to new count/scan API
On Wed, May 01, 2013 at 05:26:38PM +0200, Daniel Vetter wrote:
> On Tue, Apr 30, 2013 at 11:53 PM, Mel Gorman wrote:
> > On Sat, Apr 27, 2013 at 03:19:13AM +0400, Glauber Costa wrote:
> >> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >> b/drivers/gpu/drm/i915/i915_gem.c
> >> index 6be940e..2e44733 100644
> >> --- a/drivers/gpu/drm/i915/i915_gem.c
> >> +++ b/drivers/gpu/drm/i915/i915_gem.c
> >> @@ -1729,15 +1731,20 @@ i915_gem_purge(struct drm_i915_private *dev_priv,
> >> long target)
> >> return __i915_gem_shrink(dev_priv, target, true);
> >> }
> >>
> >> -static void
> >> +static long
> >> i915_gem_shrink_all(struct drm_i915_private *dev_priv)
> >> {
> >> struct drm_i915_gem_object *obj, *next;
> >> + long freed = 0;
> >>
> >> - i915_gem_evict_everything(dev_priv->dev);
> >> + freed += i915_gem_evict_everything(dev_priv->dev);
> >>
> >> - list_for_each_entry_safe(obj, next, &dev_priv->mm.unbound_list,
> >> gtt_list)
> >> + list_for_each_entry_safe(obj, next, &dev_priv->mm.unbound_list,
> >> gtt_list) {
> >> + if (obj->pages_pin_count == 0)
> >> + freed += obj->base.size >> PAGE_SHIFT;
> >> i915_gem_object_put_pages(obj);
> >> + }
> >> + return freed;
> >> }
> >>
> >
> > i915_gem_shrink_all is a sledge hammer! That i915_gem_evict_everything
> > looks like it switches to every GPU context, waits for everything to
> > complete and then retire it all. I don't know the details of what it's
> > doing but it's sounds very heavy handed and is called from shrinker
> > context if it fails to shrink 128 objects. Those shrinker callsback can
> > be very frequently called even from kswapd.
>
> i915_gem_shrink_all is our escape hatch, we only use it as a
> last-ditch effort when all else fails. Imo there's no point in passing
> the number of freed objects around from it since it really never
> should get called (as long as we don't get called with more objects to
> shrink than our counter counted beforehand at least).
The shrinkers can be called quite frequently so I'm concerned that you do
get called with "more objects to shrink than our counter counted beforehand"
if it's called from direct reclaim and kswapd at the same time. kswapd
can be a very frequent caller via
kswapd
balance_pgdat
shrink_slab
i915_gem_inactive_shrink
i915_gem_shrink_all
That can be active just because there is a streaming reader of a video
file that is larger than physical memory. If there is enough additional
pressure then direct reclaimers and kswapd can both call the shrinker.
The mutex on its own is not enough for them both to read "500 objects"
and then both trying to free 500 objects each with the second stalling
in i915_gem_shrink_all.
Unfortunately the laptop I'm using does not have an i915 card to check
how easy this is to trigger but I suspect filling memory with dd,
starting a video of some sort and writing to a USB stick may be enough
to trigger it.
> >> @@ -4472,3 +4470,36 @@ i915_gem_inactive_shrink(struct shrinker *shrinker,
> >> struct shrink_control *sc)
> >> mutex_unlock(&dev->struct_mutex);
> >> return cnt;
> >> }
> >> +static long
> >> +i915_gem_inactive_scan(struct shrinker *shrinker, struct shrink_control
> >> *sc)
> >> +{
> >> + struct drm_i915_private *dev_priv =
> >> + container_of(shrinker,
> >> + struct drm_i915_private,
> >> + mm.inactive_shrinker);
> >> + struct drm_device *dev = dev_priv->dev;
> >> + int nr_to_scan = sc->nr_to_scan;
> >> + long freed;
> >> + bool unlock = true;
> >> +
> >> + if (!mutex_trylock(&dev->struct_mutex)) {
> >> + if (!mutex_is_locked_by(&dev->struct_mutex, current))
> >> + return 0;
> >> +
> >
> > return -1 if it's about preventing potential deadlocks?
> >
In Glauber's series, shrinkers are split into count and scan callbacks.
If a scan returns -1, it indicates to vmscan.c that the slab could not
be shrunk at this time be it due to a deadlock risk or because the necessary
locks could not be acquired at this time.
> >> + if (dev_priv->mm.shrinker_no_lock_stealing)
> >> + return 0;
> >> +
> >
> > same?
>
> No idea. Aside, the aggressive shrinking with shrink_all and the lock
> stealing madness here are to paper our current "one lock for
> everything" approach we have for i915 gem stuff. We've papered over
> the worst offenders through lock-dropping tricks while waiting, the
> lock stealing above plus aggressively calling shrink_all.
>
> Still it's pretty trivial to (spuriously) OOM if you compete a gpu
> workload with something else. Real fix is per-object locking plus some
> watermark limits on how many pages are locked down this way, but
> that's long term (and currently stalling for the wait/wound mutexes
> from Maarten Lankhorst to get in).
>
Hmm, that's unfortunate. Later in Glauber's seri
Re: [Intel-gfx] [PATCH v4 17/31] drivers: convert shrinkers to new count/scan API
On Tue, Apr 30, 2013 at 11:53 PM, Mel Gorman wrote:
> On Sat, Apr 27, 2013 at 03:19:13AM +0400, Glauber Costa wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index 6be940e..2e44733 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -1729,15 +1731,20 @@ i915_gem_purge(struct drm_i915_private *dev_priv,
>> long target)
>> return __i915_gem_shrink(dev_priv, target, true);
>> }
>>
>> -static void
>> +static long
>> i915_gem_shrink_all(struct drm_i915_private *dev_priv)
>> {
>> struct drm_i915_gem_object *obj, *next;
>> + long freed = 0;
>>
>> - i915_gem_evict_everything(dev_priv->dev);
>> + freed += i915_gem_evict_everything(dev_priv->dev);
>>
>> - list_for_each_entry_safe(obj, next, &dev_priv->mm.unbound_list,
>> gtt_list)
>> + list_for_each_entry_safe(obj, next, &dev_priv->mm.unbound_list,
>> gtt_list) {
>> + if (obj->pages_pin_count == 0)
>> + freed += obj->base.size >> PAGE_SHIFT;
>> i915_gem_object_put_pages(obj);
>> + }
>> + return freed;
>> }
>>
>
> i915_gem_shrink_all is a sledge hammer! That i915_gem_evict_everything
> looks like it switches to every GPU context, waits for everything to
> complete and then retire it all. I don't know the details of what it's
> doing but it's sounds very heavy handed and is called from shrinker
> context if it fails to shrink 128 objects. Those shrinker callsback can
> be very frequently called even from kswapd.
i915_gem_shrink_all is our escape hatch, we only use it as a
last-ditch effort when all else fails. Imo there's no point in passing
the number of freed objects around from it since it really never
should get called (as long as we don't get called with more objects to
shrink than our counter counted beforehand at least). Also, the above
hunk is broken since i915_gem_evict_everything only unbinds object
from the gpu address space and puts them onto the unbound list, i.e.
those objects will be double-counted.
>> static int
>> @@ -4205,7 +4212,8 @@ i915_gem_load(struct drm_device *dev)
>>
>> dev_priv->mm.interruptible = true;
>>
>> - dev_priv->mm.inactive_shrinker.shrink = i915_gem_inactive_shrink;
>> + dev_priv->mm.inactive_shrinker.scan_objects = i915_gem_inactive_scan;
>> + dev_priv->mm.inactive_shrinker.count_objects = i915_gem_inactive_count;
>> dev_priv->mm.inactive_shrinker.seeks = DEFAULT_SEEKS;
>> register_shrinker(&dev_priv->mm.inactive_shrinker);
>> }
>> @@ -4428,8 +4436,8 @@ static bool mutex_is_locked_by(struct mutex *mutex,
>> struct task_struct *task)
>> #endif
>> }
>>
>> -static int
>> -i915_gem_inactive_shrink(struct shrinker *shrinker, struct shrink_control
>> *sc)
>> +static long
>> +i915_gem_inactive_count(struct shrinker *shrinker, struct shrink_control
>> *sc)
>> {
>> struct drm_i915_private *dev_priv =
>> container_of(shrinker,
>> @@ -4437,9 +4445,8 @@ i915_gem_inactive_shrink(struct shrinker *shrinker,
>> struct shrink_control *sc)
>>mm.inactive_shrinker);
>> struct drm_device *dev = dev_priv->dev;
>> struct drm_i915_gem_object *obj;
>> - int nr_to_scan = sc->nr_to_scan;
>> bool unlock = true;
>> - int cnt;
>> + long cnt;
>>
>> if (!mutex_trylock(&dev->struct_mutex)) {
>> if (!mutex_is_locked_by(&dev->struct_mutex, current))
>> @@ -4451,15 +4458,6 @@ i915_gem_inactive_shrink(struct shrinker *shrinker,
>> struct shrink_control *sc)
>> unlock = false;
>> }
>>
>> - if (nr_to_scan) {
>> - nr_to_scan -= i915_gem_purge(dev_priv, nr_to_scan);
>> - if (nr_to_scan > 0)
>> - nr_to_scan -= __i915_gem_shrink(dev_priv, nr_to_scan,
>> - false);
>> - if (nr_to_scan > 0)
>> - i915_gem_shrink_all(dev_priv);
>> - }
>> -
>> cnt = 0;
>> list_for_each_entry(obj, &dev_priv->mm.unbound_list, gtt_list)
>> if (obj->pages_pin_count == 0)
>> @@ -4472,3 +4470,36 @@ i915_gem_inactive_shrink(struct shrinker *shrinker,
>> struct shrink_control *sc)
>> mutex_unlock(&dev->struct_mutex);
>> return cnt;
>> }
>> +static long
>> +i915_gem_inactive_scan(struct shrinker *shrinker, struct shrink_control *sc)
>> +{
>> + struct drm_i915_private *dev_priv =
>> + container_of(shrinker,
>> + struct drm_i915_private,
>> + mm.inactive_shrinker);
>> + struct drm_device *dev = dev_priv->dev;
>> + int nr_to_scan = sc->nr_to_scan;
>> + long freed;
>> + bool unlock = true;
>> +
>> + if (!mutex_trylock(&dev->struct_mutex)) {
>> + if (!mutex_is_locked_by(&dev->struct_mutex, current))
>> + return 0;
>> +
>
> return -1 if it's about preventing potential deadloc
Re: [Intel-gfx] [PATCH v4 17/31] drivers: convert shrinkers to new count/scan API
On Tue, Apr 30, 2013 at 10:53:55PM +0100, Mel Gorman wrote:
> On Sat, Apr 27, 2013 at 03:19:13AM +0400, Glauber Costa wrote:
> > diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c
> > index 03e44c1..8b9c1a6 100644
> > --- a/drivers/md/bcache/btree.c
> > +++ b/drivers/md/bcache/btree.c
> > @@ -599,11 +599,12 @@ static int mca_reap(struct btree *b, struct closure
> > *cl, unsigned min_order)
> > return 0;
> > }
> >
> > -static int bch_mca_shrink(struct shrinker *shrink, struct shrink_control
> > *sc)
> > +static long bch_mca_scan(struct shrinker *shrink, struct shrink_control
> > *sc)
> > {
> > struct cache_set *c = container_of(shrink, struct cache_set, shrink);
> > struct btree *b, *t;
> > unsigned long i, nr = sc->nr_to_scan;
> > + long freed = 0;
> >
> > if (c->shrinker_disabled)
> > return 0;
>
> -1 if shrinker disabled?
>
> Otherwise if the shrinker is disabled we ultimately hit this loop in
> shrink_slab_one()
My memory is very hazy on this stuff, but I recall there being another
loop that'd just spin if we always returned -1.
(It might've been /proc/sys/vm/drop_caches, or maybe that was another
bug..)
But 0 should certainly be safe - if we're always returning 0, then we're
claiming we don't have anything to shrink.
> do {
> ret = shrinker->scan_objects(shrinker, sc);
> if (ret == -1)
> break
>
> count_vm_events(SLABS_SCANNED, batch_size);
> total_scan -= batch_size;
>
> cond_resched();
> } while (total_scan >= batch_size);
>
> which won't break as such but we busy loop until total_scan drops and
> account for SLABS_SCANNED incorrectly.
>
> More using of mutex_lock in here which means that multiple direct reclaimers
> will contend on each other. bch_mca_shrink() checks for __GFP_WAIT but an
> atomic caller does not direct reclaim so it'll always try and contend.
>
> > @@ -611,12 +612,6 @@ static int bch_mca_shrink(struct shrinker *shrink,
> > struct shrink_control *sc)
> > if (c->try_harder)
> > return 0;
> >
> > - /*
> > -* If nr == 0, we're supposed to return the number of items we have
> > -* cached. Not allowed to return -1.
> > -*/
> > - if (!nr)
> > - return mca_can_free(c) * c->btree_pages;
> >
> > /* Return -1 if we can't do anything right now */
> > if (sc->gfp_mask & __GFP_WAIT)
> > @@ -629,14 +624,14 @@ static int bch_mca_shrink(struct shrinker *shrink,
> > struct shrink_control *sc)
> >
> > i = 0;
> > list_for_each_entry_safe(b, t, &c->btree_cache_freeable, list) {
> > - if (!nr)
> > + if (freed >= nr)
> > break;
> >
> > if (++i > 3 &&
> > !mca_reap(b, NULL, 0)) {
> > mca_data_free(b);
> > rw_unlock(true, b);
> > - --nr;
> > + freed++;
> > }
> > }
> >
> > @@ -647,7 +642,7 @@ static int bch_mca_shrink(struct shrinker *shrink,
> > struct shrink_control *sc)
> > if (list_empty(&c->btree_cache))
> > goto out;
> >
> > - for (i = 0; nr && i < c->bucket_cache_used; i++) {
> > + for (i = 0; i < c->bucket_cache_used; i++) {
> > b = list_first_entry(&c->btree_cache, struct btree, list);
> > list_rotate_left(&c->btree_cache);
> >
> > @@ -656,14 +651,20 @@ static int bch_mca_shrink(struct shrinker *shrink,
> > struct shrink_control *sc)
> > mca_bucket_free(b);
> > mca_data_free(b);
> > rw_unlock(true, b);
> > - --nr;
> > + freed++;
> > } else
> > b->accessed = 0;
> > }
> > out:
> > - nr = mca_can_free(c) * c->btree_pages;
> > mutex_unlock(&c->bucket_lock);
> > - return nr;
> > + return freed;
> > +}
> > +
> > +static long bch_mca_count(struct shrinker *shrink, struct shrink_control
> > *sc)
> > +{
> > + struct cache_set *c = container_of(shrink, struct cache_set, shrink);
> > +
> > + return mca_can_free(c) * c->btree_pages;
> > }
> >
> > void bch_btree_cache_free(struct cache_set *c)
> > @@ -732,7 +733,8 @@ int bch_btree_cache_alloc(struct cache_set *c)
> > c->verify_data = NULL;
> > #endif
> >
> > - c->shrink.shrink = bch_mca_shrink;
> > + c->shrink.count_objects = bch_mca_count;
> > + c->shrink.scan_objects = bch_mca_scan;
> > c->shrink.seeks = 4;
> > c->shrink.batch = c->btree_pages * 2;
> > register_shrinker(&c->shrink);
> > diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c
> > index 4d9cca4..fa8d048 100644
> > --- a/drivers/md/bcache/sysfs.c
> > +++ b/drivers/md/bcache/sysfs.c
> > @@ -535,7 +535,7 @@ STORE(__bch_cache_set)
> > struct shrink_control sc;
> > sc.gfp_mask = GFP_KERNEL;
> > sc.nr_to_scan = strtoul_or_return(buf);
> > - c->shrink.shrink(&c-
Re: [Intel-gfx] [PATCH v4 17/31] drivers: convert shrinkers to new count/scan API
On Sat, Apr 27, 2013 at 03:19:13AM +0400, Glauber Costa wrote:
> From: Dave Chinner
>
> Convert the driver shrinkers to the new API. Most changes are
> compile tested only because I either don't have the hardware or it's
> staging stuff.
>
> FWIW, the md and android code is pretty good, but the rest of it
> makes me want to claw my eyes out. The amount of broken code I just
> encountered is mind boggling. I've added comments explaining what
> is broken, but I fear that some of the code would be best dealt with
> by being dragged behind the bike shed, burying in mud up to it's
> neck and then run over repeatedly with a blunt lawn mower.
>
> Special mention goes to the zcache/zcache2 drivers. They can't
> co-exist in the build at the same time, they are under different
> menu options in menuconfig, they only show up when you've got the
> right set of mm subsystem options configured and so even compile
> testing is an exercise in pulling teeth. And that doesn't even take
> into account the horrible, broken code...
>
> [ glommer: fixes for i915, android lowmem, zcache, bcache ]
> Signed-off-by: Dave Chinner
> Signed-off-by: Glauber Costa
Mostly glancing through. For this patch, double check where I asked
about -1's because I think some of the scanners are returning 0 when it
should be -1. Other comments on the shrinkers are drive-by comments.
Affected maintainers are now on the cc which should probably be aware of
this patch.
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 6be940e..2e44733 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1729,15 +1731,20 @@ i915_gem_purge(struct drm_i915_private *dev_priv,
> long target)
> return __i915_gem_shrink(dev_priv, target, true);
> }
>
> -static void
> +static long
> i915_gem_shrink_all(struct drm_i915_private *dev_priv)
> {
> struct drm_i915_gem_object *obj, *next;
> + long freed = 0;
>
> - i915_gem_evict_everything(dev_priv->dev);
> + freed += i915_gem_evict_everything(dev_priv->dev);
>
> - list_for_each_entry_safe(obj, next, &dev_priv->mm.unbound_list,
> gtt_list)
> + list_for_each_entry_safe(obj, next, &dev_priv->mm.unbound_list,
> gtt_list) {
> + if (obj->pages_pin_count == 0)
> + freed += obj->base.size >> PAGE_SHIFT;
> i915_gem_object_put_pages(obj);
> + }
> + return freed;
> }
>
i915_gem_shrink_all is a sledge hammer! That i915_gem_evict_everything
looks like it switches to every GPU context, waits for everything to
complete and then retire it all. I don't know the details of what it's
doing but it's sounds very heavy handed and is called from shrinker
context if it fails to shrink 128 objects. Those shrinker callsback can
be very frequently called even from kswapd.
> static int
> @@ -4205,7 +4212,8 @@ i915_gem_load(struct drm_device *dev)
>
> dev_priv->mm.interruptible = true;
>
> - dev_priv->mm.inactive_shrinker.shrink = i915_gem_inactive_shrink;
> + dev_priv->mm.inactive_shrinker.scan_objects = i915_gem_inactive_scan;
> + dev_priv->mm.inactive_shrinker.count_objects = i915_gem_inactive_count;
> dev_priv->mm.inactive_shrinker.seeks = DEFAULT_SEEKS;
> register_shrinker(&dev_priv->mm.inactive_shrinker);
> }
> @@ -4428,8 +4436,8 @@ static bool mutex_is_locked_by(struct mutex *mutex,
> struct task_struct *task)
> #endif
> }
>
> -static int
> -i915_gem_inactive_shrink(struct shrinker *shrinker, struct shrink_control
> *sc)
> +static long
> +i915_gem_inactive_count(struct shrinker *shrinker, struct shrink_control *sc)
> {
> struct drm_i915_private *dev_priv =
> container_of(shrinker,
> @@ -4437,9 +4445,8 @@ i915_gem_inactive_shrink(struct shrinker *shrinker,
> struct shrink_control *sc)
>mm.inactive_shrinker);
> struct drm_device *dev = dev_priv->dev;
> struct drm_i915_gem_object *obj;
> - int nr_to_scan = sc->nr_to_scan;
> bool unlock = true;
> - int cnt;
> + long cnt;
>
> if (!mutex_trylock(&dev->struct_mutex)) {
> if (!mutex_is_locked_by(&dev->struct_mutex, current))
> @@ -4451,15 +4458,6 @@ i915_gem_inactive_shrink(struct shrinker *shrinker,
> struct shrink_control *sc)
> unlock = false;
> }
>
> - if (nr_to_scan) {
> - nr_to_scan -= i915_gem_purge(dev_priv, nr_to_scan);
> - if (nr_to_scan > 0)
> - nr_to_scan -= __i915_gem_shrink(dev_priv, nr_to_scan,
> - false);
> - if (nr_to_scan > 0)
> - i915_gem_shrink_all(dev_priv);
> - }
> -
> cnt = 0;
> list_for_each_entry(obj, &dev_priv->mm.unbound_list, gtt_list)
> if (obj->pages_pin_count == 0)
> @@ -4472,3 +4470,36 @@ i915_gem_inactive_shrink(struct shrinker *shrinker,
> struct shrink_control *sc
