On 04/30/2013 05:22 PM, Mel Gorman wrote:
> On Sat, Apr 27, 2013 at 03:18:58AM +0400, Glauber Costa wrote:
>> In very low free kernel memory situations, it may be the case that we
>> have less objects to free than our initial batch size. If this is the
>> case, it is better to shrink those, and open space for the new workload
>> then to keep them and fail the new allocations.
>>
>> More specifically, this happens because we encode this in a loop with
>> the condition: "while (total_scan >= batch_size)". So if we are in such
>> a case, we'll not even enter the loop.
>>
>> This patch modifies turns it into a do () while {} loop, that will
>> guarantee that we scan it at least once, while keeping the behaviour
>> exactly the same for the cases in which total_scan > batch_size.
>>
>> Signed-off-by: Glauber Costa <glommer@xxxxxxxxxx>
>> Reviewed-by: Dave Chinner <david@xxxxxxxxxxxxx>
>> Reviewed-by: Carlos Maiolino <cmaiolino@xxxxxxxxxx>
>> CC: "Theodore Ts'o" <tytso@xxxxxxx>
>> CC: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
>
> There are two cases where this *might* cause a problem and worth keeping
> an eye out for.
>
Any test case that you envision that could help bringing those issues
forward should they exist ? (aside from getting it into upstream trees
early?)
>
> Neither potential issue are the fault of your patch so I'm not going
> to nack. However, bear in mind that we should watch out for bugs where
> processes stall making forward progress because they are constantly
> reallocating inodes or bugs like graphics stalls because their objects
> keep getting fully reclaimed as only a small number exist.
>
> I suspect that you need this patch because it's very reasonable for a memcg
> to have slabs with tiny numbers of objects you want to reclaim.
Precisely.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>