From mboxrd@z Thu Jan 1 00:00:00 1970 From: KOSAKI Motohiro Subject: Re: [PATCH 6/6] vmscan: Kick flusher threads to clean pages when reclaim is encountering dirty pages Date: Mon, 2 Aug 2010 16:57:18 +0900 (JST) Message-ID: <20100802133259.4F89.A69D9226@jp.fujitsu.com> References: <20100801170115.4AFC.A69D9226@jp.fujitsu.com> <1280679686.3081.28.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: kosaki.motohiro@jp.fujitsu.com, Andrew Morton , Mel Gorman , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Dave Chinner , Nick Piggin , Rik van Riel , Johannes Weiner , Christoph Hellwig , Wu Fengguang , KAMEZAWA Hiroyuki , Andrea Arcangeli To: Trond Myklebust , Chris Mason Return-path: In-Reply-To: <1280679686.3081.28.camel@heimdal.trondhjem.org> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org Hi > The problem that I am seeing is that the try_to_release_page() needs to > be told to act as a non-blocking call when the process is kswapd, just > like the pageout() call. >=20 > Currently, the sc->gfp_mask is set to GFP_KERNEL, which normally means > that the call may wait on I/O to complete. However, what I'm seeing in > the bugzilla above is that if kswapd waits on an RPC call, then the > whole VM may gum up: typically, the traces show that the socket layer > cannot allocate memory to hold the RPC reply from the server, and so it > is kicking kswapd to have it reclaim some pages, however kswapd is stuc= k > in try_to_release_page() waiting for that same I/O to complete, hence > the deadlock... Ah, I see. so as far as I understand, you mean - Socket layer use GFP_ATOMIC, then they don't call try_to_free_pages(). IOW, kswapd is only memory reclaiming thread. - Kswapd got stuck in ->release_page(). - In usual use case, another thread call kmalloc(GFP_KERNEL) and makes foreground reclaim, then, restore kswapd stucking. but your case there is no such thread. Hm, interesting. In short term, current nfs fix (checking PF_MEMALLOC in nfs_wb_page()) seems best way. it's no side effect if my understanding is correct. > IOW: I think kswapd at least should be calling try_to_release_page() > with a gfp-flag of '0' to avoid deadlocking on I/O. Hmmm. 0 seems to have very strong meanings rather than nfs required.=20 There is no reason to prevent grabbing mutex, calling cond_resched() etc = etc... [digging old git history] Ho hum... Old commit log says passing gfp-flag=3D0 break xfs. but current xfs doesn= 't use gfp_mask argument. hm. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D commit 68678e2fc6cfdfd013a2513fe416726f3c05b28d Author: akpm Date: Tue Sep 10 18:09:08 2002 +0000 [PATCH] pass the correct flags to aops->releasepage() Restore the gfp_mask in the VM's call to a_ops->releasepage(). We ca= n block in there again, and XFS (at least) can use that. BKrev: 3d7e35445skDsKDFM6rdiwTY-5elsw diff --git a/mm/vmscan.c b/mm/vmscan.c index 5ed1ec3..89d801e 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -208,7 +208,7 @@ shrink_list(struct list_head *page_list, int nr_pages= , * Otherwise, leave the page on the LRU so it is swappabl= e. */ if (PagePrivate(page)) { - if (!try_to_release_page(page, 0)) + if (!try_to_release_page(page, gfp_mask)) goto keep_locked; if (!mapping && page_count(page) =3D=3D 1) goto free_it; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Now, gfp_mask of try_to_release_page() are used in two place. btrfs: btrfs_releasepage (check GFP_WAIT) nfs: nfs_release_page ((gfp & GFP_KERNEL) =3D=3D GFP_KERNEL) Probably, btrfs can remove such GFP_WAIT check from try_release_extent_ma= pping because it doesn't sleep. I dunno. if so, we can change it to 0 again. bu= t I'm not sure it has enough worth thing. Chris, can we hear how btrfs handle gfp_mask argument of release_page()? btw, VM fokls need more consider kswapd design. now kswapd oftern sleep. But Trond's bug report says, waiting itself can makes deadlock potentiall= y. Perhaps it's merely imagine thing. but need to some consider... -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org