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: > > On Thu, Sep 22, 2016 at 05:24:25PM -0700, Omar Sandoval wrote: > > > From: Omar Sandoval <osan...@fb.com> > > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
