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 from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
