On Fri, Sep 23, 2016 at 09:52:01AM -0700, Omar Sandoval wrote:

On Fri, Sep 23, 2016 at 11:27:27AM +0200, David Sterba wrote:

quoted

On Thu, Sep 22, 2016 at 05:24:25PM -0700, Omar Sandoval wrote:

quoted

From: Omar Sandoval <redacted>

test_find_delalloc() allocates 256 MB worth of pages. That's all of the
RAM that my MIPS emulator has, so it ends up panicking after it OOM
kills everything. We don't actually need to use that much for this test.

I'm not sure we should limit it that way as more bytes can give it more
stress. Can we do it somehow dynamically ? Like start with 256M and fall
back to the numbers you've used.

Or maybe start from the low bound and allocate until it fails with first
ENOMEM.

I figured out how to get qemu to do highmem on MIPS, so we can drop this
patch. It's reasonable to assume that the sanity tests are running on a
machine with a decent amount of memory.

I lied, that didn't fix the problem for me, since these page allocations
can't use highmem. Anyways, the tests seem to be testing more for logic
errors manipulating the extent io tree, so just scaling it down
shouldn't be a huge issue, right?

The problem with relying on ENOMEM for anything is that the OOM killer
will kick in before we actually get the ENOMEM. I tried adding
__GFP_NORETRY, which claims that it doesn't invoke the OOM killer, but
it still did :(

Anyways, Cc Josef to see what he thinks since he wrote the test.

-- 
Omar