On Mon, 6 Feb 2012, Rik van Riel wrote: > On 02/06/2012 03:49 PM, Andrew Morton wrote: > > On Mon, 6 Feb 2012 11:40:08 -0800 (PST) > > Hugh Dickins<hughd@xxxxxxxxxx> wrote: > > > > > I get this lockdep warning from swapping load on linux-next > > > (20120201 but I expect the same from more recent days): > > > > The patch looks good as a standalone optimisation/cleanup. The lack of > > clarity on the lockdep thing is a concern - I have a feeling we'll be > > bitten again. > > Very strange, kswapd does not seem to be holding any locks > when calling balance_pgdat... > > I assume it must be this line in kswapd() that's causing > lockdep to trigger: > > lockdep_set_current_reclaim_state(GFP_KERNEL); Certainly that's a part of what's bringing lockdep's GFP_FS checking into play. And I noticed that that does get modulated by whether PF_MEMALLOC is set or not: maybe it needs another PF_MEMALLOC check somewhere, maybe it's correct as is, I just don't pretend to know. (Earlier on I moved the lockdep_set_current_reclaim_state call after kswapd sets PF_MEMALLOC; but that's irrelevant and doesn't help, I was simply misunderstanding what goes on.) If we had an lru_add_drain_all() somewhere in the direct reclaim path, then I'm sure lockdep would be right to complain. It notices that we once did a GFP_KERNEL allocation while holding pcpu_alloc_mutex, so it would protest at trying to acquire pcpu_alloc_mutex down in direct reclaim. But whether that renders the call in kswapd dangerous or not, I don't know: I forget the extent to which the limitations of direct reclaim require kswapd to make progress - imagine a task holding pcpu_alloc_mutex going down into direct reclaim, getting nowhere, and needing kswapd to make progress, but kswapd wants to take pcpu_alloc_mutex to compact_pgdat. Hugh -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>