On Mon, Nov 04, 2019 at 10:29:39AM -0500, Brian Foster wrote:
> On Fri, Nov 01, 2019 at 10:46:01AM +1100, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@xxxxxxxxxx>
> >
> > Start to clean up the shrinker code by factoring out the calculation
> > that determines how much work to do. This separates the calculation
> > from clamping and other adjustments that are done before the
> > shrinker work is run. Document the scan batch size calculation
> > better while we are there.
> >
> > Also convert the calculation for the amount of work to be done to
> > use 64 bit logic so we don't have to keep jumping through hoops to
> > keep calculations within 32 bits on 32 bit systems.
> >
> > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
> > ---
>
> I assume the kbuild warning thing will be fixed up...
>
> > mm/vmscan.c | 97 ++++++++++++++++++++++++++++++++++++++---------------
> > 1 file changed, 70 insertions(+), 27 deletions(-)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index a215d71d9d4b..2d39ec37c04d 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -459,13 +459,68 @@ EXPORT_SYMBOL(unregister_shrinker);
> >
> > #define SHRINK_BATCH 128
> >
> > +/*
> > + * Calculate the number of new objects to scan this time around. Return
> > + * the work to be done. If there are freeable objects, return that number in
> > + * @freeable_objects.
> > + */
> > +static int64_t shrink_scan_count(struct shrink_control *shrinkctl,
> > + struct shrinker *shrinker, int priority,
> > + int64_t *freeable_objects)
> > +{
> > + int64_t delta;
> > + int64_t freeable;
> > +
> > + freeable = shrinker->count_objects(shrinker, shrinkctl);
> > + if (freeable == 0 || freeable == SHRINK_EMPTY)
> > + return freeable;
> > +
> > + if (shrinker->seeks) {
> > + /*
> > + * shrinker->seeks is a measure of how much IO is required to
> > + * reinstantiate the object in memory. The default value is 2
> > + * which is typical for a cold inode requiring a directory read
> > + * and an inode read to re-instantiate.
> > + *
> > + * The scan batch size is defined by the shrinker priority, but
> > + * to be able to bias the reclaim we increase the default batch
> > + * size by 4. Hence we end up with a scan batch multipler that
> > + * scales like so:
> > + *
> > + * ->seeks scan batch multiplier
> > + * 1 4.00x
> > + * 2 2.00x
> > + * 3 1.33x
> > + * 4 1.00x
> > + * 8 0.50x
> > + *
> > + * IOWs, the more seeks it takes to pull the item into cache,
> > + * the smaller the reclaim scan batch. Hence we put more reclaim
> > + * pressure on caches that are fast to repopulate and to keep a
> > + * rough balance between caches that have different costs.
> > + */
> > + delta = freeable >> (priority - 2);
>
> Does anything prevent priority < 2 here?
Nope. I regularly see priority 1 here when the OOM killer is about
to strike. Doesn't appear to have caused any problems - the scan
counts have all come out correct (i.e. ends up as a >> 0) according
to the tracing, but I'll fix this up to avoid hitting this.
>
> > - delta = freeable >> priority;
> > - delta *= 4;
> > - do_div(delta, shrinker->seeks);
> > - } else {
> > - /*
> > - * These objects don't require any IO to create. Trim
> > - * them aggressively under memory pressure to keep
> > - * them from causing refetches in the IO caches.
> > - */
> > - delta = freeable / 2;
> > - }
> > -
> > - total_scan += delta;
> > + total_scan = nr + scan_count;
> > if (total_scan < 0) {
> > pr_err("shrink_slab: %pS negative objects to delete nr=%ld\n",
> > shrinker->scan_objects, total_scan);
> > - total_scan = freeable;
> > + total_scan = scan_count;
>
> Same question as before: why the change in assignment? freeable was the
> ->count_objects() return value, which is now stored in freeable_objects.
we don't want to try to free the entire cache on an 64-bit integer
overflow. scan_count is the work we calculated we need to do this
shrinker invocation, so if we overflow because of other factors then
we should just do the work we need to do in this scan.
> FWIW, the change seems to make sense in that it just factors out the
> deferred count, but it's not clear if it's intentional...
It was intentional.
-Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
