From: "Darrick J. Wong" <djwong@kernel.org>
To: Wengang Wang <wen.gang.wang@oracle.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 7/9] spaceman/defrag: sleeps between segments
Date: Tue, 9 Jul 2024 13:46:06 -0700 [thread overview]
Message-ID: <20240709204606.GU612460@frogsfrogsfrogs> (raw)
In-Reply-To: <20240709191028.2329-8-wen.gang.wang@oracle.com>
On Tue, Jul 09, 2024 at 12:10:26PM -0700, Wengang Wang wrote:
> Let user contol the time to sleep between segments (file unlocked) to
> balance defrag performance and file IO servicing time.
>
> Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
> ---
> spaceman/defrag.c | 26 ++++++++++++++++++++++++--
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/spaceman/defrag.c b/spaceman/defrag.c
> index b5c5b187..415fe9c2 100644
> --- a/spaceman/defrag.c
> +++ b/spaceman/defrag.c
> @@ -311,6 +311,9 @@ void defrag_sigint_handler(int dummy)
> */
> static long g_limit_free_bytes = 1024 * 1024 * 1024;
>
> +/* sleep time in us between segments, overwritten by paramter */
> +static int g_idle_time = 250 * 1000;
> +
> /*
> * check if the free space in the FS is less than the _limit_
> * return true if so, false otherwise
> @@ -487,6 +490,7 @@ defrag_xfs_defrag(char *file_path) {
> int scratch_fd = -1, defrag_fd = -1;
> char tmp_file_path[PATH_MAX+1];
> struct file_clone_range clone;
> + int sleep_time_us = 0;
> char *defrag_dir;
> struct fsxattr fsx;
> int ret = 0;
> @@ -574,6 +578,9 @@ defrag_xfs_defrag(char *file_path) {
>
> /* checks for EoF and fix up clone */
> stop = defrag_clone_eof(&clone);
> + if (sleep_time_us > 0)
> + usleep(sleep_time_us);
> +
> gettimeofday(&t_clone, NULL);
> ret = ioctl(scratch_fd, FICLONERANGE, &clone);
> if (ret != 0) {
> @@ -587,6 +594,10 @@ defrag_xfs_defrag(char *file_path) {
> if (time_delta > max_clone_us)
> max_clone_us = time_delta;
>
> + /* sleeps if clone cost more than 500ms, slow FS */
Why half a second? I sense that what you're getting at is that you want
to limit file io latency spikes in other programs by relaxing the defrag
program, right? But the help screen doesn't say anything about "only if
the clone lasts more than 500ms".
> + if (time_delta >= 500000 && g_idle_time > 0)
> + usleep(g_idle_time);
These days, I wonder if it makes more sense to provide a CPU utilization
target and let the kernel figure out how much sleeping that is:
$ systemd-run -p 'CPUQuota=60%' xfs_spaceman -c 'defrag' /path/to/file
The tradeoff here is that we as application writers no longer have to
implement these clunky sleeps ourselves, but then one has to turn on cpu
accounting in systemd (if there even /is/ a systemd). Also I suppose we
don't want this program getting throttled while it's holding a file
lock.
--D
> +
> /* for defrag stats */
> nr_ext_defrag += segment.ds_nr;
>
> @@ -641,6 +652,12 @@ defrag_xfs_defrag(char *file_path) {
>
> if (stop || usedKilled)
> break;
> +
> + /*
> + * no lock on target file when punching hole from scratch file,
> + * so minus the time used for punching hole
> + */
> + sleep_time_us = g_idle_time - time_delta;
> } while (true);
> out:
> if (scratch_fd != -1) {
> @@ -678,6 +695,7 @@ static void defrag_help(void)
> " -f free_space -- specify shrethod of the XFS free space in MiB, when\n"
> " XFS free space is lower than that, shared segments \n"
> " are excluded from defragmentation, 1024 by default\n"
> +" -i idle_time -- time in ms to be idle between segments, 250ms by default\n"
> " -n -- disable the \"share first extent\" featue, it's\n"
> " enabled by default to speed up\n"
> ));
> @@ -691,7 +709,7 @@ defrag_f(int argc, char **argv)
> int i;
> int c;
>
> - while ((c = getopt(argc, argv, "s:f:n")) != EOF) {
> + while ((c = getopt(argc, argv, "s:f:ni")) != EOF) {
> switch(c) {
> case 's':
> g_segment_size_lmt = atoi(optarg) * 1024 * 1024 / 512;
> @@ -709,6 +727,10 @@ defrag_f(int argc, char **argv)
> g_enable_first_ext_share = false;
> break;
>
> + case 'i':
> + g_idle_time = atoi(optarg) * 1000;
Should we complain if optarg is non-integer garbage? Or if g_idle_time
is larger than 1s?
--D
> + break;
> +
> default:
> command_usage(&defrag_cmd);
> return 1;
> @@ -726,7 +748,7 @@ void defrag_init(void)
> defrag_cmd.cfunc = defrag_f;
> defrag_cmd.argmin = 0;
> defrag_cmd.argmax = 4;
> - defrag_cmd.args = "[-s segment_size] [-f free_space] [-n]";
> + defrag_cmd.args = "[-s segment_size] [-f free_space] [-i idle_time] [-n]";
> defrag_cmd.flags = CMD_FLAG_ONESHOT;
> defrag_cmd.oneline = _("Defragment XFS files");
> defrag_cmd.help = defrag_help;
> --
> 2.39.3 (Apple Git-146)
>
>
next prev parent reply other threads:[~2024-07-09 20:46 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-09 19:10 [PATCH 0/9] introduce defrag to xfs_spaceman Wengang Wang
2024-07-09 19:10 ` [PATCH 1/9] xfsprogs: introduce defrag command to spaceman Wengang Wang
2024-07-09 21:18 ` Darrick J. Wong
2024-07-11 21:54 ` Wengang Wang
2024-07-15 21:30 ` Wengang Wang
2024-07-15 22:44 ` Darrick J. Wong
2024-07-09 19:10 ` [PATCH 2/9] spaceman/defrag: pick up segments from target file Wengang Wang
2024-07-09 21:50 ` [PATCH 2/9] spaceman/defrag: pick up segments from target fileOM Darrick J. Wong
2024-07-11 22:37 ` Wengang Wang
2024-07-15 23:40 ` [PATCH 2/9] spaceman/defrag: pick up segments from target file Dave Chinner
2024-07-16 20:23 ` Wengang Wang
2024-07-17 4:11 ` Dave Chinner
2024-07-18 19:03 ` Wengang Wang
2024-07-19 4:59 ` Dave Chinner
2024-07-19 4:01 ` Christoph Hellwig
2024-07-24 19:22 ` Wengang Wang
2024-07-30 22:13 ` Dave Chinner
2024-07-09 19:10 ` [PATCH 3/9] spaceman/defrag: defrag segments Wengang Wang
2024-07-09 21:57 ` Darrick J. Wong
2024-07-11 22:49 ` Wengang Wang
2024-07-12 19:07 ` Wengang Wang
2024-07-15 22:42 ` Darrick J. Wong
2024-07-16 0:08 ` Dave Chinner
2024-07-18 18:06 ` Wengang Wang
2024-07-09 19:10 ` [PATCH 4/9] spaceman/defrag: ctrl-c handler Wengang Wang
2024-07-09 21:08 ` Darrick J. Wong
2024-07-11 22:58 ` Wengang Wang
2024-07-15 22:56 ` Darrick J. Wong
2024-07-16 16:21 ` Wengang Wang
2024-07-09 19:10 ` [PATCH 5/9] spaceman/defrag: exclude shared segments on low free space Wengang Wang
2024-07-09 21:05 ` Darrick J. Wong
2024-07-11 23:08 ` Wengang Wang
2024-07-15 22:58 ` Darrick J. Wong
2024-07-09 19:10 ` [PATCH 6/9] spaceman/defrag: workaround kernel xfs_reflink_try_clear_inode_flag() Wengang Wang
2024-07-09 20:51 ` Darrick J. Wong
2024-07-11 23:11 ` Wengang Wang
2024-07-16 0:25 ` Dave Chinner
2024-07-18 18:24 ` Wengang Wang
2024-07-31 22:25 ` Dave Chinner
2024-07-09 19:10 ` [PATCH 7/9] spaceman/defrag: sleeps between segments Wengang Wang
2024-07-09 20:46 ` Darrick J. Wong [this message]
2024-07-11 23:26 ` Wengang Wang
2024-07-11 23:30 ` Wengang Wang
2024-07-09 19:10 ` [PATCH 8/9] spaceman/defrag: readahead for better performance Wengang Wang
2024-07-09 20:27 ` Darrick J. Wong
2024-07-11 23:29 ` Wengang Wang
2024-07-16 0:56 ` Dave Chinner
2024-07-18 18:40 ` Wengang Wang
2024-07-31 3:10 ` Dave Chinner
2024-08-02 18:31 ` Wengang Wang
2024-07-09 19:10 ` [PATCH 9/9] spaceman/defrag: warn on extsize Wengang Wang
2024-07-09 20:21 ` Darrick J. Wong
2024-07-11 23:36 ` Wengang Wang
2024-07-16 0:29 ` Dave Chinner
2024-07-22 18:01 ` Wengang Wang
2024-07-30 22:43 ` Dave Chinner
2024-07-15 23:03 ` [PATCH 0/9] introduce defrag to xfs_spaceman Dave Chinner
2024-07-16 19:45 ` Wengang Wang
2024-07-31 2:51 ` Dave Chinner
2024-08-02 18:14 ` Wengang Wang
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=20240709204606.GU612460@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=wen.gang.wang@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox