[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220826101522.b552tn646qobrjdx@quack3>
Date: Fri, 26 Aug 2022 12:15:22 +0200
From: Jan Kara <jack@...e.cz>
To: Stefan Wahren <stefan.wahren@...e.com>
Cc: Jan Kara <jack@...e.cz>, Ted Tso <tytso@....edu>,
linux-ext4@...r.kernel.org,
Thorsten Leemhuis <regressions@...mhuis.info>,
Ojaswin Mujoo <ojaswin@...ux.ibm.com>,
Harshad Shirwadkar <harshadshirwadkar@...il.com>
Subject: Re: [PATCH 0/2] ext4: Fix performance regression with mballoc
Hi Stefan,
On Thu 25-08-22 18:57:08, Stefan Wahren wrote:
> > Perhaps if you just download the archive manually, call sync(1), and measure
> > how long it takes to (untar the archive + sync) in mb_optimize_scan=0/1 we
> > can see whether plain untar is indeed making the difference or there's
> > something else influencing the result as well (I have checked and
> > rpi-update does a lot of other deleting & copying as the part of the
> > update)? Thanks.
>
> mb_optimize_scan=0 -> almost 5 minutes
>
> mb_optimize_scan=1 -> almost 18 minutes
>
> https://github.com/lategoodbye/mb_optimize_scan_regress/commit/3f3fe8f87881687bb654051942923a6b78f16dec
Thanks! So now the iostat data indeed looks substantially different.
nooptimize optimize
Total written 183.6 MB 190.5 MB
Time (recorded) 283 s 1040 s
Avg write request size 79 KB 41 KB
So indeed with mb_optimize_scan=1 we do submit substantially smaller
requests on average. So far I'm not sure why that is. Since Ojaswin can
reproduce as well, let's see what he can see from block location info.
Thanks again for help with debugging this and enjoy your vacation!
Honza
--
Jan Kara <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists