All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Omar Sandoval <osandov@osandov.com>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com,
	Chandan Rajendra <chandan@linux.vnet.ibm.com>,
	Anatoly Pugachev <matorola@gmail.com>,
	Josef Bacik <jbacik@fb.com>
Subject: Re: [PATCH v2 6/6] Btrfs: use less memory for delalloc sanity tests
Date: Mon, 26 Sep 2016 17:58:02 +0200	[thread overview]
Message-ID: <20160926155802.GC16983@suse.cz> (raw)
In-Reply-To: <20160923212253.GA15294@vader>

On Fri, Sep 23, 2016 at 02:22:53PM -0700, Omar Sandoval wrote:
> 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 <osandov@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 :(

I think we cannot rely on NORETRY behaviour wrt OOM killer anyway. For
now I'd rather leave out the patch and let people test on machines with
enough memory. Any furhter ideas to make it work on low memory are
welcome but I don't want to block this patchset.

  reply	other threads:[~2016-09-26 16:00 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-23  0:22 [PATCH v2 0/6] Btrfs: free space tree and sanity test fixes Omar Sandoval
2016-09-23  0:24 ` [PATCH v2 1/6] Btrfs: fix free space tree bitmaps on big-endian systems Omar Sandoval
2016-09-23 14:37   ` Holger Hoffstätte
2016-09-23  0:24 ` [PATCH v2 2/6] Btrfs: fix mount -o clear_cache,space_cache=v2 Omar Sandoval
2016-09-23 14:37   ` Holger Hoffstätte
2016-09-23  0:24 ` [PATCH v2 3/6] Btrfs: catch invalid free space trees Omar Sandoval
2016-09-23 14:40   ` Holger Hoffstätte
2016-09-24 19:50   ` Hans van Kranenburg
2016-09-26 17:39     ` Omar Sandoval
2016-09-26 17:46       ` Hans van Kranenburg
2016-09-26 17:52         ` Omar Sandoval
2016-09-26 23:13   ` Omar Sandoval
2016-09-29 11:43     ` David Sterba
2016-09-23  0:24 ` [PATCH v2 4/6] Btrfs: fix extent buffer bitmap tests on big-endian systems Omar Sandoval
2016-09-23  0:24 ` [PATCH v2 5/6] Btrfs: expand free space tree sanity tests to catch endianness bug Omar Sandoval
2016-09-23  0:24 ` [PATCH v2 6/6] Btrfs: use less memory for delalloc sanity tests Omar Sandoval
2016-09-23  9:27   ` David Sterba
2016-09-23 16:52     ` Omar Sandoval
2016-09-23 21:22       ` Omar Sandoval
2016-09-26 15:58         ` David Sterba [this message]
2016-09-26 17:33           ` Omar Sandoval
2016-09-25  7:55 ` [PATCH v2 0/6] Btrfs: free space tree and sanity test fixes Anatoly Pugachev
2016-09-26 17:50   ` David Sterba
2016-09-26 17:56     ` Omar Sandoval
2016-09-29 12:21     ` Anatoly Pugachev
2016-09-29 12:52       ` Holger Hoffstätte
2016-09-29 13:02         ` Anatoly Pugachev
2016-09-29 14:29           ` David Sterba
2016-10-01  9:26             ` Anatoly Pugachev
2016-09-26 17:51   ` Omar Sandoval
2016-09-28 13:03 ` Chandan Rajendra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160926155802.GC16983@suse.cz \
    --to=dsterba@suse.cz \
    --cc=chandan@linux.vnet.ibm.com \
    --cc=jbacik@fb.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=matorola@gmail.com \
    --cc=osandov@osandov.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.