[Top] [All Lists]

Re: [PATCH] mm: add gfp_mask parameter to vm_map_ram()

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH] mm: add gfp_mask parameter to vm_map_ram()
From: David Rientjes <rientjes@xxxxxxxxxx>
Date: Wed, 13 Jun 2012 20:53:42 -0700 (PDT)
Cc: Minchan Kim <minchan@xxxxxxxxxx>, Fengguang Wu <fengguang.wu@xxxxxxxxx>, Dave Chinner <dchinner@xxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Tejun Heo <tj@xxxxxxxxxx>, Linux Memory Management List <linux-mm@xxxxxxxxx>, xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type; bh=0iihbz1YndKAYkH0Ktwoz36bam4zH8oqiJ7+QfPUJoY=; b=OIDvFW6IGMOYUFMZufYc0p3rnnjG9AD4Muyy/048IMtb3ZmmTSsfHwuhWHg8MkSImL t958Yz26xOwBXWJFyBP59n/sxdahkgWgHFkdj0hWb+AX/q1SE+7pyyp2/UxFxPAKDYkr BDb0n4rMC+IIM+D3BP86LjW1tx8ukvMNdLGg2ealpKKsUF/yp/z8yGw/+ngODAc264d2 QNdy4ZXExDmRVO4rjHnNWakVZwqJ8Y+i6GdmSaaI/K9B0+W6HUC5yBu6fOa5L8ICS0Bb iUEHuAY0Tij/aV9rl12Yb1blz6sudrwuRSjvnNVY00v+Bic66163g69qIKlbKwJKLhQI aifg==
In-reply-to: <20120614033429.GD7339@dastard>
References: <20120612012134.GA7706@localhost> <20120613123932.GA1445@localhost> <20120614012026.GL3019@xxxxxxxxxxxxxxxx> <20120614014902.GB7289@localhost> <4FD94779.3030108@xxxxxxxxxx> <20120614033429.GD7339@dastard>
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Thu, 14 Jun 2012, Dave Chinner wrote:

> Oh, please. I have been hearing this for years, and are we any
> closer to it? No, we are further away from ever being able to
> acheive this than ever. Face it, filesystems require memory
> allocation to write dirty data to disk, and the amount is almost
> impossible to define. Hence mempools can't be used because we can't
> give any guarantees of forward progress. And for vmalloc?
> Filesystems widely use vmalloc/vm_map_ram because kmalloc fails on
> large contiguous allocations. This renders kmalloc unfit for
> purpose, so we have to fall back to single page allocation and
> vm_map_ram or vmalloc so that the filesystem can function properly.
> And to avoid deadlocks, all memory allocation must be able to
> specify GFP_NOFS to prevent the MM subsystem from recursing into the
> filesystem. Therefore, vmalloc needs to support GFP_NOFS.
> I don't care how you make it happen, just fix it. Trying to place
> the blame on the filesystem folk for using vmalloc in GFP_NOFS
> contexts is a total and utter cop-out, because mm folk of all people
> should know that non-zero order kmalloc is not a reliable
> alternative....

I'd actually like to see a demonstrated problem (i.e. not theoretical) 
where vmalloc() stalls indefinitely because its passed GFP_NOFS.  I've 
never seen one reported.

This is because the per-arch pte allocators have hardwired GFP_KERNEL 
flags, but then again they also have __GFP_REPEAT which would cause them 
to loop infinitely in the page allocator if a page was not reclaimed, 
which has little success without __GFP_FS.  But nobody has ever reported a 
livelock that was triaged back to passing !__GFP_FS to vmalloc().

<Prev in Thread] Current Thread [Next in Thread>