Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752824AbbBBG5l (ORCPT ); Mon, 2 Feb 2015 01:57:41 -0500 Received: from linuxhacker.ru ([217.76.32.60]:37457 "EHLO fiona.linuxhacker.ru" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1751257AbbBBG5k convert rfc822-to-8bit (ORCPT ); Mon, 2 Feb 2015 01:57:40 -0500 Subject: Re: [PATCH] gfs2: use __vmalloc GFP_NOFS for fs-related allocations. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Oleg Drokin In-Reply-To: <20150202053708.GG4251@dastard> Date: Mon, 2 Feb 2015 01:57:23 -0500 Cc: Steven Whitehouse , cluster-devel@redhat.com, Linux Kernel Mailing List , linux-mm@kvack.org Content-Transfer-Encoding: 8BIT Message-Id: References: <1422849594-15677-1-git-send-email-green@linuxhacker.ru> <20150202053708.GG4251@dastard> To: Dave Chinner X-Mailer: Apple Mail (2.1283) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1980 Lines: 51 Hello! On Feb 2, 2015, at 12:37 AM, Dave Chinner wrote: > On Sun, Feb 01, 2015 at 10:59:54PM -0500, green@linuxhacker.ru wrote: >> From: Oleg Drokin >> >> leaf_dealloc uses vzalloc as a fallback to kzalloc(GFP_NOFS), so >> it clearly does not want any shrinker activity within the fs itself. >> convert vzalloc into __vmalloc(GFP_NOFS|__GFP_ZERO) to better achieve >> this goal. >> >> Signed-off-by: Oleg Drokin >> --- >> fs/gfs2/dir.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/fs/gfs2/dir.c b/fs/gfs2/dir.c >> index c5a34f0..6371192 100644 >> --- a/fs/gfs2/dir.c >> +++ b/fs/gfs2/dir.c >> @@ -1896,7 +1896,8 @@ static int leaf_dealloc(struct gfs2_inode *dip, u32 index, u32 len, >> >> ht = kzalloc(size, GFP_NOFS | __GFP_NOWARN); >> if (ht == NULL) >> - ht = vzalloc(size); >> + ht = __vmalloc(size, GFP_NOFS | __GFP_NOWARN | __GFP_ZERO, >> + PAGE_KERNEL); > That, in the end, won't help as vmalloc still uses GFP_KERNEL > allocations deep down in the PTE allocation code. See the hacks in > the DM and XFS code to work around this. i.e. go look for callers of > memalloc_noio_save(). It's ugly and grotesque, but we've got no > other way to limit reclaim context because the MM devs won't pass > the vmalloc gfp context down the stack to the PTE allocations.... Hm, interesting. So all the other code in the kernel that does this sort of thing (and there's quite a bit outside of xfs and ocfs2) would not get the desired effect? So, I did some digging in archives and found this thread from 2010 onward with various patches and rants. Not sure how I missed that before. Should we have another run at this I wonder? Bye, Oleg-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/