Re: [PATCH v10 29/35] memcg: per-memcg kmem shrinking

Glauber Costa
2013-06-06T08:35:33Z

On 06/06/2013 03:08 AM, Andrew Morton wrote:
>> +
>> > + /*
>> > + * We will try to shrink kernel memory present in caches. We
>> > + * are sure that we can wait, so we will. The duration of our
>> > + * wait is determined by congestion, the same way as vmscan.c
>> > + *
>> > + * If we are in FS context, though, then although we can wait,
>> > + * we cannot call the shrinkers. Most fs shrinkers (which
>> > + * comprises most of our kmem data) will not run without
>> > + * __GFP_FS since they can deadlock. The solution is to
>> > + * synchronously run that in a different context.
> But this is pointless. Calling a function via a different thread and
> then waiting for it to complete is equivalent to calling it directly.
>
Not in this case. We are in wait-capable context (we check for this
right before we reach this), but we are not in fs capable context.

So the reason we do this - which I tried to cover in the changelog, is
to escape from the GFP_FS limitation that our call chain has, not the
wait limitation.