fstests.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: djwong@kernel.org, guaneryu@gmail.com
Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me
Subject: [PATCH 2/2] generic/643: fix weird problems on 64k-page arm systems
Date: Tue, 31 Aug 2021 17:11:21 -0700	[thread overview]
Message-ID: <163045508165.769821.10102236634811320096.stgit@magnolia> (raw)
In-Reply-To: <163045507051.769821.5924414818977330640.stgit@magnolia>

From: Darrick J. Wong <djwong@kernel.org>

I noticed the following regression on an arm64 system with 64k pages:

--- generic/643.out
+++ generic/643.out.bad
@@ -1,2 +1,3 @@
 QA output created by 643
+swapon added 960 pages, expected 896
 Silence is golden

Evidently mkswap writes the swapfile header advertising one memory page
less than the size of the file, and on some architectures the kernel
can sometimes grab one page less than what's advertised.  This variance
is weird but tolerable; we simply don't want to see the page count
doubling when the file size doubles.

While we're at it, include the commit id of the fix in the commit
message.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 tests/generic/643     |   33 ++++++++++++++++++++++-----------
 tests/generic/643.out |    2 +-
 2 files changed, 23 insertions(+), 12 deletions(-)


diff --git a/tests/generic/643 b/tests/generic/643
index 2bb9d220..7a1d3ec7 100755
--- a/tests/generic/643
+++ b/tests/generic/643
@@ -4,8 +4,10 @@
 #
 # FS QA Test No. 643
 #
-# Regression test for "mm/swap: consider max pages in iomap_swapfile_add_extent"
-
+# Regression test for commit:
+#
+# 36ca7943ac18 ("mm/swap: consider max pages in iomap_swapfile_add_extent")
+#
 # Xu Yu found that the iomap swapfile activation code failed to constrain
 # itself to activating however many swap pages that the mm asked us for.  This
 # is an deviation in behavior from the classic swapfile code.  It also leads to
@@ -22,6 +24,8 @@ _cleanup()
 	test -n "$swapfile" && swapoff $swapfile &> /dev/null
 }
 
+. ./common/filter
+
 # real QA test starts here
 _supported_fs generic
 _require_scratch_swapfile
@@ -34,29 +38,36 @@ _scratch_mount >> $seqres.full
 swapfile=$SCRATCH_MNT/386spart.par
 _format_swapfile $swapfile 1m >> $seqres.full
 
-swapfile_pages() {
+page_size=$(getconf PAGE_SIZE)
+
+swapfile_blocks() {
 	local swapfile="$1"
 
 	grep "$swapfile" /proc/swaps | awk '{print $3}'
 }
 
 _swapon_file $swapfile
-before_pages=$(swapfile_pages "$swapfile")
+before_blocks=$(swapfile_blocks "$swapfile")
 swapoff $swapfile
 
 # Extend the length of the swapfile but do not rewrite the header.
-# The subsequent swapon should set up 1MB worth of pages, not 2MB.
+# The subsequent swapon should set up 1MB worth of blocks, not 2MB.
 $XFS_IO_PROG -f -c 'pwrite 1m 1m' $swapfile >> $seqres.full
 
 _swapon_file $swapfile
-after_pages=$(swapfile_pages "$swapfile")
+after_blocks=$(swapfile_blocks "$swapfile")
 swapoff $swapfile
 
-# Both swapon attempts should have found the same number of pages.
-test "$before_pages" -eq "$after_pages" || \
-	echo "swapon added $after_pages pages, expected $before_pages"
+# Both swapon attempts should have found approximately the same number of
+# blocks.  Unfortunately, mkswap and the kernel are a little odd -- the number
+# of pages that mkswap writes into the swapfile header is one page less than
+# the file size, and then the kernel itself doesn't always grab all the pages
+# advertised in the header.  Hence we let the number of swap pages increase by
+# two pages.  I'm looking at you, Mr. 64k pages on arm64...
+page_variance=$(( page_size / 512 ))
+_within_tolerance "swap blocks" $after_blocks $before_blocks 0 $page_variance -v
+
+echo "pagesize: $page_size; before: $before_blocks; after: $after_blocks" >> $seqres.full
 
-# success, all done
-echo Silence is golden
 status=0
 exit
diff --git a/tests/generic/643.out b/tests/generic/643.out
index 32f1c629..1b14d66e 100644
--- a/tests/generic/643.out
+++ b/tests/generic/643.out
@@ -1,2 +1,2 @@
 QA output created by 643
-Silence is golden
+swap blocks is in range


  parent reply	other threads:[~2021-09-01  0:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01  0:11 [PATCHSET 0/2] fstests: random fixes Darrick J. Wong
2021-09-01  0:11 ` [PATCH 1/2] common/xfs: skip xfs_check unless the test runner forces us to Darrick J. Wong
2021-09-01  8:30   ` Christoph Hellwig
2021-09-01  9:24   ` Zorro Lang
2021-09-01  0:11 ` Darrick J. Wong [this message]
2021-09-01  8:34   ` [PATCH 2/2] generic/643: fix weird problems on 64k-page arm systems Christoph Hellwig

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=163045508165.769821.10102236634811320096.stgit@magnolia \
    --to=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=guan@eryu.me \
    --cc=guaneryu@gmail.com \
    --cc=linux-xfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).