[PATCH] vmscan: reduce wind up shrinker->nr when shrinker can't dowork

[Dave Chinner]

>>     while (total_scan >= batch_size) ...
>>
>> With this biasing, it is impossible to achieve the ideal behavior I've
>> described above, because we will never accumulate max_pass objects in
>> nr_deferred if memory pressure is low. So, if applied to the real code,
>> this patch takes on a slightly different sense, which I tried to reflect
>> in the comment to the code: it will call ->scan() with nr_to_scan <
>> batch_size only if:
>>
>> 1) max_pass < batch_size && total_scan >= max_pass
>>
>> and
>>
>> 2) we're tight on memory, i.e. the current delta is high (otherwise
>> total_scan will be biased as max_pass / 2 and condition 1 won't be
>> satisfied).
> (is max_pass misnamed?)

Yes, the name is misleading. I guess, it should be called freeable_cnt,
because we actually scan up to 2*max_pass objects in one pass.

>> >From our discussion it seems condition 2 is not necessary at all, but it
>> follows directly from the biasing rule. So I propose to tweak the
>> biasing a bit so that total_scan won't be lowered < batch_size:
>>
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index eea668d..78ddd5e 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -267,7 +267,7 @@ shrink_slab_node(struct shrink_control *shrinkctl,
>> struct shrinker *shrinker,
>>       * a large delta change is calculated directly.
>>       */
>>      if (delta < max_pass / 4)
>> -        total_scan = min(total_scan, max_pass / 2);
>> +        total_scan = min(total_scan, max(max_pass / 2, batch_size));
>>  
>>      /*
>>       * Avoid risking looping forever due to too large nr value:
>> @@ -281,7 +281,7 @@ shrink_slab_node(struct shrink_control *shrinkctl,
>> struct shrinker *shrinker,
>>                  nr_pages_scanned, lru_pages,
>>                  max_pass, delta, total_scan);
>>  
>> -    while (total_scan >= batch_size) {
>> +    while (total_scan >= batch_size || total_scan >= max_pass) {
>>          unsigned long ret;
>>  
>>          shrinkctl->nr_to_scan = batch_size;
>>
>> The first hunk guarantees that total_scan will always accumulate at
>> least batch_size objects no matter how small max_pass is. That means
>> that when max_pass is < batch_size we will eventually get >= max_pass
>> objects to scan and shrink the slab to 0 as we need. What do you think
>> about that?
> I'm a bit lost :(

I'll try to clean up shrink_slab_node() and resend the patch then.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/