From: David Laight <David.Laight@ACULAB.COM>
To: 'Damien Le Moal' <damien.lemoal@opensource.wdc.com>,
John Garry <john.garry@huawei.com>,
kernel test robot <oliver.sang@intel.com>
Cc: Christoph Hellwig <hch@lst.de>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
LKML <linux-kernel@vger.kernel.org>,
"Linux Memory Management List" <linux-mm@kvack.org>,
"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
"lkp@lists.01.org" <lkp@lists.01.org>,
"lkp@intel.com" <lkp@intel.com>,
"ying.huang@intel.com" <ying.huang@intel.com>,
"feng.tang@intel.com" <feng.tang@intel.com>,
"zhengjun.xing@linux.intel.com" <zhengjun.xing@linux.intel.com>,
"fengwei.yin@intel.com" <fengwei.yin@intel.com>
Subject: RE: [ata] 0568e61225: stress-ng.copy-file.ops_per_sec -15.0% regression
Date: Tue, 9 Aug 2022 15:16:26 +0000 [thread overview]
Message-ID: <c4b45c0e06af473abe17e3471e1bb948@AcuMS.aculab.com> (raw)
In-Reply-To: <e4106ffa-3842-45c0-9756-5226cfcfa17d@opensource.wdc.com>
...
> >> Without knowing what the device adapter is, hard to say where the problem is. I
> >> suspect that with the patch applied, we may be ending up with a small default
> >> max_sectors value, causing overhead due to more commands than necessary.
> >>
> >> Will check what I see with my test rig.
> >
> > As far as I can see, this patch should not make a difference unless the
> > ATA shost driver is setting the max_sectors value unnecessarily low.
>
> That is my hunch too, hence my question about which host driver is being used
> for this test... That is not apparent from the problem report.
No one's fallen over the old problem and managed to limit
the number of sectors in a read to the number of sectors
in (IIRC) a 'multi sector' read that uses a single DMA burst?
Was always a good way of killing disk performance.
IIRC the maximum number of sectors for an ATA disk transfer is 255.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2022-08-09 15:16 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-05 8:05 kernel test robot
2022-08-08 14:52 ` Damien Le Moal
2022-08-09 9:58 ` John Garry
2022-08-09 14:16 ` John Garry
2022-08-09 14:57 ` Damien Le Moal
2022-08-10 8:33 ` John Garry
2022-08-10 13:52 ` Damien Le Moal
2022-08-09 14:55 ` Damien Le Moal
2022-08-09 15:16 ` David Laight [this message]
2022-08-10 13:57 ` Damien Le Moal
2022-08-12 5:01 ` Oliver Sang
2022-08-12 11:13 ` John Garry
2022-08-12 14:58 ` John Garry
2022-08-16 6:57 ` Oliver Sang
2022-08-16 10:35 ` John Garry
2022-08-16 15:42 ` Damien Le Moal
2022-08-16 16:38 ` John Garry
2022-08-16 20:02 ` Damien Le Moal
2022-08-16 20:44 ` John Garry
2022-08-17 15:55 ` Damien Le Moal
2022-08-17 13:51 ` Oliver Sang
2022-08-17 14:04 ` John Garry
2022-08-18 2:06 ` Oliver Sang
2022-08-18 9:28 ` John Garry
2022-08-19 6:24 ` Oliver Sang
2022-08-19 7:54 ` John Garry
2022-08-20 16:36 ` Damien Le Moal
2022-08-12 15:41 ` Damien Le Moal
2022-08-12 17:17 ` John Garry
2022-08-12 18:27 ` Damien Le Moal
2022-08-13 7:23 ` John Garry
2022-08-16 2:52 ` Oliver Sang
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=c4b45c0e06af473abe17e3471e1bb948@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=damien.lemoal@opensource.wdc.com \
--cc=feng.tang@intel.com \
--cc=fengwei.yin@intel.com \
--cc=hch@lst.de \
--cc=john.garry@huawei.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=lkp@lists.01.org \
--cc=martin.petersen@oracle.com \
--cc=oliver.sang@intel.com \
--cc=ying.huang@intel.com \
--cc=zhengjun.xing@linux.intel.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