Hello, On Wed, Dec 14, 2011 at 12:22:34PM -0500, Vivek Goyal wrote: > [..] > > __GFP_WAIT isn't the problem, you can block in the IO path. You cannot, > > however, recurse back into IO submission. That's why CFQ is using > > GFP_NOIO, implying that waiting is OK, but submitting new IO to satisfy > > the allocation is not. > > Ok. Got it. So even if we implement mutex_is_locked() check, it does not > protect me from possiblity of per cpu allocation path recursing into > IO submission. That means, there needs to be a variant of per cpu > allocation which can take the allocation flags as parameter and honor > these flags. Slightly tangential but we actually have a bug here. Under high enough memory pressure, ioc or cic allocation can fail which will make request alloc fail and retry, which isn't guaranteed to make forward progress. struct request itself is mempool backed but ioc/cic aren't. It seems hitting this problem (and thus IO / memalloc deadlock) isn't too difficult w/ memcg. An easy fix would be using INSERT_BACK instead of INSERT_SORT if elevator_set() fails. I'll soon post patches to fix the problem. > > > Or may be there is a safer version of pcpu alloc which will return > > > without allocation if pcpu_alloc_mutex is already locked. pcpu alloc depends on vmalloc allocation, so it isn't trivial. We can try to make percpu keep cache of areas for this type of allocation but I personally think doing percpu allocation from atomic context or IO path is a bad idea. Hmmm... Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
