[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <28c71b3c-2f96-9962-22fd-eb707346a3c4@intel.com>
Date: Fri, 25 Feb 2022 17:35:42 +0800
From: Yujie Liu <yujie.liu@...el.com>
To: Qu Wenruo <quwenruo.btrfs@....com>, Qu Wenruo <wqu@...e.com>
CC: Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
<dsterba@...e.com>, <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
<linux-btrfs@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<llvm@...ts.linux.dev>, Souptick Joarder <jrdr.linux@...il.com>,
kernel test robot <lkp@...el.com>
Subject: Re: [PATCH] btrfs: Initialize ret to 0 in scrub_simple_mirror()
Hi Qu,
On 2/24/2022 17:56, Qu Wenruo wrote:
>>
>> For clang analyzer reports, usually we do internal check firstly. We'll
>> send out the
>> report only when we think that it is highly possible to be a true alert.
>
> BTW, do performance benchmarks also go through the same procedure?
> Yes, runtime reports(including boot test, performance benchmarks,
etc.) also go through internal check procedure, but compared with
build issues, sometimes we are not that confident about performance
regressions.
> Although your bots are awesome at detect compiling warning/errors,
> sometimes it's not that straightforward to reproduce the same
> performance regressions.
>
> So it may be worthy some extra steps to verify certain performance
> regressions.
>
Runtime issues are much complicated than build issues, the
performance may fluctuate depending on different software and
hardware environment, so not that straightforward to reproduce.
Please feel free to contact LKP folks if found any false reports of
regressions or any issues in reproducing steps. We can learn more
experience from user feedback and keep optimizing our work flow to
improve the accuracy of catching real regressions.
Thanks,
Yujie
Powered by blists - more mailing lists