All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] [RFC] zram01: Fix on ppc64le
Date: Thu, 2 Feb 2017 16:22:42 +0100	[thread overview]
Message-ID: <20170202152242.GA11304@rei.lan> (raw)
In-Reply-To: <1372516698.1369615.1485946778720.JavaMail.zimbra@redhat.com>

Hi!
> > > This is ~4 years old comment from Zach Brown, when I hit an issue on ppc,
> > > where I could alloc only 1/2 of the volume size:
> > > 
> > > "That small volume mkfs warning is issued for devices less than a gig.  It
> > > indicates that btrfs has gone in to a weird degenerate allocation scheme.
> > > We'd only support volumes much larger than that, though I have no quick
> > > rule to say how large starts to be reasonable.  Multiple gig, certainly."
> > > 
> > > I'm running with 384M since then, so far successfully. If we don't allocate
> > > too much data on it, we might be OK, but still I'd go with minimum default
> > > of 256M.
> > 
> > What exactly do you have in mind? Using 256MB by default for any Btrfs
> > filesystem or fallback to 256MB if mkfs.btrfs output cannot be parsed?
> 
> I meant default size.

Then we should increase the default size for the LTP_DEV as well.
Unfortunately it's defined at three different places at this point. We
have it in runltp script, the C library and the shell library. I was
thinking of exporting the C library as a binary for the shell tests to
use in order to reduce the complexity. I will look into that and also
bump the minimal size as well.

> > I guess that for any other testcase it would be fine enough to bump the
> > minimal device size to 256MB unconditionally, but in this case we create
> > the data in RAM albeit compressed, and so I would like to keep it as
> > small as possible, since otherwise it may fail on embedded hardware.
> 
> I didn't have a look at zram01, but can't we detect this and TCONF?

I guess that we can look at total amount of RAM and enable/disable the
test with Btrfs filesystem if it's deemed too small.

> We can try with minimum and see how frequently it changes, I just
> wanted to share Zach's quote and my experience with tiny btrfs volumes.

I've been adjusting the minimal size (of the TST_DEVICE) two times
already, we bumped it to 100MB then to 150MB. The first one was
because mkfs.btrfs change, the second was because the size depends on
PAGE_SIZE and 100MB wasn't enough for ppc64le. I guess that bumping it
to 256MB is not unreasonable, and hopefully that would be enough for
some time.

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2017-02-02 15:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-31 13:44 [LTP] [PATCH] [RFC] zram01: Fix on ppc64le Cyril Hrubis
2017-01-31 16:14 ` Jan Stancek
2017-02-01  9:45   ` Cyril Hrubis
2017-02-01 10:59     ` Jan Stancek
2017-02-02 15:22       ` Cyril Hrubis [this message]
2017-02-08 11:10         ` Cyril Hrubis
2017-02-09 12:02           ` Cyril Hrubis
2017-02-09 13:24             ` Jan Stancek
2017-02-09 14:00               ` Cyril Hrubis
2017-02-09 14:48                 ` Jan Stancek
2017-02-09 14:56                   ` Cyril Hrubis
2017-08-15  9:23 ` Cyril Hrubis
2017-08-15 11:44   ` Jan Stancek
2017-08-15 12:38     ` Cyril Hrubis
2017-08-15 12:48       ` Jan Stancek
2017-08-15 12:57         ` Cyril Hrubis

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=20170202152242.GA11304@rei.lan \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /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.