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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--
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>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]