On 02/01/2016 12:29 AM, Dave Chinner wrote:
On Thu, Jan 28, 2016 at 11:04:23PM +0100, Michal Hocko wrote:
On Fri 29-01-16 07:55:25, Dave Chinner wrote:
On Tue, Jan 26, 2016 at 10:50:23AM +0100, Michal Hocko wrote:
[...]
There have been patches posted during the year to fortify those places
which cannot cope with allocation failures for ext[34] and testing
has shown that ext* resp. xfs are quite ready to see NOFS allocation
failures.
The XFS situation is compeletely unchanged from last year, and the
fact that you say it handles NOFS allocation failures just fine
makes me seriously question your testing methodology.
I am quite confused now. I remember you were the one who complained
about the silent nofail behavior of the allocator because that means
you cannot implement an appropriate fallback strategy.
I complained about the fact the allocator did not behave as
documented (or expected) in that it didn't fail allocations we
expected it to fail.
Yes, I believe this is exactly what Michal was talking about in the
original e-mail:
- GFP_NOFS is another one which would be good to discuss. Its primary
use is to prevent from reclaim recursion back into FS. This makes
such an allocation context weaker and historically we haven't
triggered OOM killer and rather hopelessly retry the request and
rely on somebody else to make a progress for us. There are two issues
here.
First we shouldn't retry endlessly and rather fail the allocation and
allow the FS to handle the error. As per my experiments most FS cope
with that quite reasonably. Btrfs unfortunately handles many of those
failures by BUG_ON which is really unfortunate.
So this should address your complain above.
That being said, I do understand that allowing GFP_NOFS allocation to
fail is not an easy task and nothing to be done tomorrow or in few
months, but I believe that a discussion with FS people about what
can/should be done in order to make this happen is valuable.
The discussion - from my perspective - is likely to be no different
to previous years. None of the proposals that FS people have come up
to address the "need memory allocation guarantees" issue have got
any traction on the mm side. Unless there's something fundamentally
new from the MM side that provides filesystems with a replacement
for __GFP_NOFAIL type behaviour, I don't think further discussion is
going to change the status quo.
Yeah, the guaranteed reserves as discussed last year didn't happen so
far. But that's a separate issue than GPF_NOFS *without* __GFP_NOFAIL.
It just got mixed up in this thread.
Cheers,
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
