From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD8F7C36008 for ; Wed, 26 Mar 2025 21:10:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 80EED2800AE; Wed, 26 Mar 2025 17:10:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EF1F2800A5; Wed, 26 Mar 2025 17:10:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 687412800AE; Wed, 26 Mar 2025 17:10:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 48D262800A5 for ; Wed, 26 Mar 2025 17:10:53 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 64E85C1255 for ; Wed, 26 Mar 2025 21:10:54 +0000 (UTC) X-FDA: 83264946828.08.2E59DC5 Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by imf29.hostedemail.com (Postfix) with ESMTP id 63852120004 for ; Wed, 26 Mar 2025 21:10:52 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=rYwkAuAA; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf29.hostedemail.com: domain of david@fromorbit.com designates 209.85.216.49 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743023452; a=rsa-sha256; cv=none; b=wiGqTAMJpvjf1S47PFQsyInzP9TwGI3RN1WDdKdtoccZprQOB+hkM4nz3iWLATbhwiTCUk q+3FFlNE0RM3rzDeuFrIFHg4FmT+QO09t807A741KGlNZdJsMXyk4U1hmpzUBt0IxH6Dgx YciCM59OQkxemn6O+ePh4E6Te06AH3Q= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=rYwkAuAA; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf29.hostedemail.com: domain of david@fromorbit.com designates 209.85.216.49 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743023452; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8r5zblQElbPQO87GHLZRnHgdEdr+1fSpbnjgQJ9+CIo=; b=0do6fc50ZlyozpvS7bnyRnVMiq7MyG/+APx4Q35Qh8fySghvFZW6bGWq0ZoIkDjQuYXxJE vpgHTg/Rgwj2GuhSKzdQMi8S7Gwwi3biCI2cm4g+NjefuXo3J3Bk8An1HiveGkDhrNEmPm fSLoq9JdOv/O6qfXhlIouJjN15jqoKA= Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-3014678689aso391097a91.0 for ; Wed, 26 Mar 2025 14:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1743023451; x=1743628251; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=8r5zblQElbPQO87GHLZRnHgdEdr+1fSpbnjgQJ9+CIo=; b=rYwkAuAA/cU20vh6ZICxbP/CozkCusRp+XN3iME/bVVSZ9SykR+sV06iPlk6YHDI9u 4r9qyYpmF+bCqRqXaTaJtYPiyu0BFgUpC3x1CY6TAG0S4/we+3qAghoGS7amIBSx/sXs DUO1ENiMx6HjpGkfbGYUkt0v8KbAZKBKfAUEXkw8nCOdrVj4nOJpjHirDhKi2e7N7/Cy CK+TURsV0odixEXaek9Wqk3uo97d3t1hIFe9ClGmAhoROFkY6aR5hdGtozlaYCJJecHz iIvAXWIWetKMIsauRmvXCKBUiRLMEcDX0B5mFovYRvxykWeMJpFnou+sPGW7hKn7ZBud FURQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743023451; x=1743628251; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8r5zblQElbPQO87GHLZRnHgdEdr+1fSpbnjgQJ9+CIo=; b=XCLVkaLfFR3U184bAcYTLf8BC1teKiTRCR0VSakZXDK3kAIbuFtDswAl6jEHosGupC Gu+tAtYLzOuQMv4AdVLV8oMBWksQSof7ecnawR7XQm+HCiNWG+8kHjFsqlZXES1k3WBd K6VJPHqtIhCl7qanKVUE238YrX/0SyzfyhrpfO94gY7vfMsGMUtb2pNVTRXJ7btRqNdw KfA0+MGtaeegDtBYU9oA1WmrWmVARh7UP37opt1uElNhwnI2gPtidfXIJylyUNJhCSXt vwaq5FE4NWiPNo8gmS8yfAJXs60I3NSSfRsN9pfkxU4mhCm21ZVhq71gxaJ1zkPposjE ZvHw== X-Forwarded-Encrypted: i=1; AJvYcCXR92CTysPd9nstPrHC/s1JvySr5vjhteP8X9aDMhpA/yNSRQlD+01hWDVM/q/1cvK6U9//rmZaow==@kvack.org X-Gm-Message-State: AOJu0Yy33VCn2vwDOG9lKmD59V2HvyPAlvSR86m8GIVBbgUrJwtRK9u6 4cxs4tUwzaGdkHG7inPahHCHMTCb/TUN9OQmJff8n4ZhMoe42lSe3jWps1vRD6iD/StMrXQ3UEL + X-Gm-Gg: ASbGncs/x6PGSUDN6PIdDbWeS6be5y/pe8wgdpu00f3bwSCI9RczaSymIgh+hyFPpou cX+xYv2aoyxsoXuxj+Lluymk6AvtASqQL0rCna2jjkpAasLbuM7JdflFSYSLx58xcxqXO8xMFNq ybJrog1AwKcwQGCeW95S0GbLX6CUbM2TuqxrdAXMW6+WMdyH19sh+L6LpkhFYDqxDNyU5eU0Epa U141rkFZa8h2Xh38SD/v/acnrJi7CD8sfJLSLzZLHHfx9FljDsODtIKHwI+CW5rOYk2Z2DSGdMB xevvivdxwaorNSdx2m5NLIeLl+rCwlX0XKnwsHj1OYnJVCetseN3bksTGtnkP2NDuPJn9FcUYam 7oiRY8O0= X-Google-Smtp-Source: AGHT+IH74ag5XeN4ls7BanUgMSLHcrsUvl+HEw2fiukQfAGjZxR0vReelBylQGQRPmjYWqz5PrQAvw== X-Received: by 2002:a17:90a:d2cb:b0:2ff:7b28:a51a with SMTP id 98e67ed59e1d1-303a815a72cmr2059828a91.17.1743023450937; Wed, 26 Mar 2025 14:10:50 -0700 (PDT) Received: from dread.disaster.area (pa49-181-60-96.pa.nsw.optusnet.com.au. [49.181.60.96]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-227811b2ae1sm114999645ad.114.2025.03.26.14.10.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Mar 2025 14:10:50 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.98) (envelope-from ) id 1txY1P-00000000h3J-1N9l; Thu, 27 Mar 2025 08:10:47 +1100 Date: Thu, 27 Mar 2025 08:10:47 +1100 From: Dave Chinner To: Luis Chamberlain Cc: patches@lists.linux.dev, fstests@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, oliver.sang@intel.com, hannes@cmpxchg.org, willy@infradead.org, jack@suse.cz, apopple@nvidia.com, brauner@kernel.org, hare@suse.de, oe-lkp@lists.linux.dev, lkp@intel.com, john.g.garry@oracle.com, p.raghav@samsung.com, da.gomez@samsung.com, dave@stgolabs.net, riel@surriel.com, krisman@suse.de, boris@bur.io, jackmanb@google.com, gost.dev@samsung.com Subject: Re: [PATCH] generic/764: fsstress + migrate_pages() test Message-ID: References: <20250326185101.2237319-1-mcgrof@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250326185101.2237319-1-mcgrof@kernel.org> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 63852120004 X-Stat-Signature: wpirxpx1ajf79aim934j8zanwdjp1ttu X-Rspam-User: X-HE-Tag: 1743023452-304936 X-HE-Meta: U2FsdGVkX1+ugGOAsFKiIXPf383mbXu3pxpv6k2YIPEvcQsOOW1XIqwfFZLFPn8enQlF6lCHC9eZ9zejoESMFxEuLeyE6H/h4mmRZEmyjDZzjthW9efxGVk0n3As3ycN13vyqER90NmrpBa0f/afi200t2McupYzdkaG/xvYTOl1HnkvH11rP+ftFETWvTzEWIAh3h9jyO5GKeB7KsErNDMl/phWcN8fV0F7DqsGA62rO08yw/G1k+QFk9ex/7BaYx1xZ7yAxFIpbpRUP7jOlIp/vuBYVs2whxKCpRCID8g238iatzVqcB1Jhs/g38Ep/aiun+iG4LAtbB4FUiOWKwlveR3GkK/UVlXHR9M/p5FSj/SnH1q8xo9WmdpYy9scm9ibNCHBOeyGRCLT6mf8P5E4ooY+zradqwGXGAUyupHsNQumYAh9CnJJvXbWCxn5g3srIMixFf7wgVNYCkQzCG4eE2lFi+xB7CjwyHtXqrpkZ0ZCQFWoPLJf0BneFXg8unrpMD2iHNjlzkyQ5VY+EqbxLdxm/vhKkgtBAMVNXIrDJogdPi3Uw/fd58x3ny6LvbW1hAjsih1eQmKp0Ge93+F1pIiV6aEFvShtCnEnXCz8aXmQ3XLD4dbW0QmB4yZXVSl2LbsknksCFvfMb4YSdmOGMQTyIlxhlSGvJK6J2QN5FVPAc5Mr5PDojEtwF6Pmn/eExpF8bQ3vUEiHh0mD9l1Gh7ylKW48z5dqI4CRYBK0VlkyR2InKK+qY7mCzp/cc3k0Z6KK/HBiVmcIJDtyW4ajUdjqnAFBltJMtUUbSegfH+L5dn4lassgQzl6EncvQnxEYXyQA367joY3GLSqLsapic4xz5mSFXFosPYgxIAXMSCt+gvhqNH7ancxaUkM2jF79qiGAGKxZ4YPqrUbyhtKs3exB6p1mN1hSp8R/enKDPgFOSTzVQWQFNxfME9lg9FTFVQDoo5f4nGDv85 d8zXfwX/ Fu/J1JK32AhOdUXta9W+OmjyC1IXW1+ZdBK5XFpht3PkSY71Yce/Hv/otW+MnsCbPVdGH/5L/gzP9Rh/IrHlkSBVVVtZSy2OO3UnIhjiP/eQ3pkY407jeN3pxUuN8/RiOvY8GK741KugfQre5REq2GOBpjMX+JpxFIJWFwF5Nvv/NZcq5dJf2EN2TAbYPqrFVu5wPTK1lFrc5fJXs17pE1vYPAbA6rXhCkuouuGckx5Qec50QbCu47IXhMSdFFpDAUKhEienNnM26h6gxy2RYoiMfwsQzk0Fx6o+JDQTmAMuTp4KQGHz2t3A1OI3xUkcQVtJaElUwnCcuBiyHDXy6dEceJiuytHbL2RGqQruj9Xc/FzqC7KmnOi7gwoKuRJEgrDXNL+hL1UeegMSHqLWQvgrPwyJuhepbX9SOC7aN9JDvwFfQfUol1u78lLHf+I3/MSbjYuuFUByu6vO8nMcvOF7WUOtWI+4Eo3ebl3Ufehi3rSxnq4HIDbxwxjgvlCOeecviId7TLj9rzf/EIRuQK9u7Czz/oC77qBhauVev6lPKB42JyTuX9A9vFA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.003243, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Mar 26, 2025 at 11:50:55AM -0700, Luis Chamberlain wrote: > 0-day reported a page migration kernel warning with folios which happen > to be buffer-heads [0]. I'm having a terribly hard time reproducing the bug > and so I wrote this test to force page migration filesystems. > > It turns out we have have no tests for page migration on fstests or ltp, > and its no surprise, other than compaction covered by generic/750 there > is no easy way to trigger page migration right now unless you have a > numa system. > > We should evaluate if we want to help stress test page migration > artificially by later implementing a way to do page migration on simple > systems to an artificial target. > > So far, this doesn't trigger any kernel splats, not even warnings for me. > > Reported-by: kernel test robot > Link: https://lore.kernel.org/r/202503101536.27099c77-lkp@intel.com # [0] > Signed-off-by: Luis Chamberlain > --- > common/config | 2 + > common/rc | 8 ++++ > tests/generic/764 | 94 +++++++++++++++++++++++++++++++++++++++++++ > tests/generic/764.out | 2 + > 4 files changed, 106 insertions(+) > create mode 100755 tests/generic/764 > create mode 100644 tests/generic/764.out > > diff --git a/common/config b/common/config > index 2afbda141746..93b50f113b44 100644 > --- a/common/config > +++ b/common/config > @@ -239,6 +239,8 @@ export BTRFS_MAP_LOGICAL_PROG=$(type -P btrfs-map-logical) > export PARTED_PROG="$(type -P parted)" > export XFS_PROPERTY_PROG="$(type -P xfs_property)" > export FSCRYPTCTL_PROG="$(type -P fscryptctl)" > +export NUMACTL_PROG="$(type -P numactl)" > +export MIGRATEPAGES_PROG="$(type -P migratepages)" > > # udev wait functions. > # > diff --git a/common/rc b/common/rc > index e51686389a78..ed9613a9bf28 100644 > --- a/common/rc > +++ b/common/rc > @@ -281,6 +281,14 @@ _require_vm_compaction() > fi > } > > +_require_numa_nodes() > +{ > + readarray -t QUEUE < <($NUMACTL_PROG --show | awk '/^membind:/ {for (i=2; i<=NF; i++) print $i}') sed makes this easier: remove the membind token, then remove all the lines that have ":"s left in them. This leaves behind the membind node string. $ numactl --show | sed -e 's/membind://' -e '/:/d' 0 1 2 3 $ Also should have: _require_command "$NUMACTL_PROG" "numactl" built into it, rather than requiring the test to declare it first. > + if (( ${#QUEUE[@]} < 2 )); then > + _notrun "You need a system with at least two numa nodes to run this test" > + fi > +} > + > # Requires CONFIG_DEBUGFS and truncation knobs > _require_split_huge_pages_knob() > { > diff --git a/tests/generic/764 b/tests/generic/764 > new file mode 100755 > index 000000000000..91d9fb7e08da > --- /dev/null > +++ b/tests/generic/764 > @@ -0,0 +1,94 @@ > +#! /bin/bash > +# SPDX-License-Identifier: GPL-2.0 > +# Copyright (c) 2024 Luis Chamberlain. All Rights Reserved. > +# > +# FS QA Test 764 > +# > +# fsstress + migrate_pages() test > +# > +. ./common/preamble > +_begin_fstest auto rw long_rw stress soak smoketest > + > +_cleanup() > +{ > + cd / > + rm -f $runfile > + rm -f $tmp.* > + kill -9 $run_migration_pid > /dev/null 2>&1 > + kill -9 $stress_pid > /dev/null 2>&1 > + > + wait > /dev/null 2>&1 > +} If you implement this using the fsstress wrappers like I mention below, and get rid of running the main migration loop in background, this cleanup function can go away completely. > + > +_require_scratch > +_require_command "$NUMACTL_PROG" "numactl" > +_require_command "$MIGRATEPAGES_PROG" "migratepages" > +_require_numa_nodes > + > +readarray -t QUEUE < <($NUMACTL_PROG --show | awk '/^membind:/ {for (i=2; i<=NF; i++) print $i}') > +if (( ${#QUEUE[@]} < 2 )); then > + echo "Not enough NUMA nodes to pick two different ones." > + exit 1 > +fi You've implemented this twice. > +echo "Silence is golden" > + > +_scratch_mkfs > $seqres.full 2>&1 > +_scratch_mount >> $seqres.full 2>&1 > + > +nr_cpus=$((LOAD_FACTOR * 4)) > +nr_ops=$((25000 * nr_cpus * TIME_FACTOR)) Don't scale ops with nr_cpus - you've already scaled processes with nr_cpus. > +fsstress_args=(-w -d $SCRATCH_MNT -n $nr_ops -p $nr_cpus) > +test -n "$SOAK_DURATION" && fsstress_args+=(--duration="$SOAK_DURATION") > + > +runfile="$tmp.migratepages" > +pidfile="$tmp.stress.pid" > + > +run_stress_fs() > +{ > + $FSSTRESS_PROG $FSSTRESS_AVOID "${fsstress_args[@]}" & > + stress_pid=$! > + echo $stress_pid > $pidfile > + wait $stress_pid > + rm -f $runfile > + rm -f $pidfile > +} Don't reimplement _run_fsstress(), call it instead. > + > +run_stress_fs & Actually, you want _run_fsstress_bg() here, and then _kill_fsstress() when you want it to die. > +touch $runfile > +stress_pid=$(cat $pidfile) Don't need either of these. > + > +while [ -e $runfile ]; do while [ -n "_FSSTRESS_PID" ]; do > + readarray -t QUEUE < <(numactl --show | awk '/^membind:/ {for (i=2; i<=NF; i++) print $i}') Third time this is implemented. > + # Proper Fisher–Yates shuffle > + for ((i=${#QUEUE[@]} - 1; i > 0; i--)); do > + j=$((RANDOM % (i + 1))) > + var=${QUEUE[i]} > + QUEUE[i]=${QUEUE[j]} > + QUEUE[j]=$var > + done > + > + RANDOM_NODE_1=${QUEUE[0]} > + RANDOM_NODE_2=${QUEUE[1]} If all you are doing is picking two random nodes, then you could just use RANDOM for the array index and drop the whole shuffle thing, yes? > + if [[ -f $pidfile ]]; then no need for this if we gate the loop on _FSSTRESS_PID > + echo "migrating parent fsstress process:" >> $seqres.full > + echo -en "\t$MIGRATEPAGES_PROG $pid $RANDOM_NODE_1 $RANDOM_NODE_2 ..." >> $seqres.full > + $MIGRATEPAGES_PROG $stress_pid $RANDOM_NODE_1 $RANDOM_NODE_2 > + echo " $?" >> $seqres.full > + echo "migrating child fsstress processes ..." >> $seqres.full > + for pid in $(ps --ppid "$stress_pid" -o pid=); do > + echo -en "\tmigratepages $pid $RANDOM_NODE_1 $RANDOM_NODE_2 ..." >> $seqres.full > + $MIGRATEPAGES_PROG $pid $RANDOM_NODE_1 $RANDOM_NODE_2 > + echo " $?" >> $seqres.full > + done > + fi > + sleep 2 > +done & > +run_migration_pid=$! why is this put in the background, only to then wait on it to complete? The loop will stop when fsstress finishes, yes? Which means this doesn't need to be run in the background at all, and then cleanup doesn't need to handle killing this, either. -Dave. -- Dave Chinner david@fromorbit.com