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
next prev 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).