Re: [ata] 0568e61225: stress-ng.copy-file.ops_per_sec -15.0% regression

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/08/2022 10:58, John Garry wrote:

commit: 0568e6122574dcc1aded2979cd0245038efe22b6 ("ata: libata-scsi: cap ata_device->max_sectors according to shost->max_sectors")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master

in testcase: stress-ng
on test machine: 96 threads 2 sockets Ice Lake with 256G memory
with following parameters:

    nr_threads: 10%
    disk: 1HDD
    testtime: 60s
    fs: f2fs
    class: filesystem
    test: copy-file
    cpufreq_governor: performance
    ucode: 0xb000280

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.

For __ATA_BASE_SHT, we don't set max_sectors. As such, we default shost->max_sectors = SCSI_DEFAULT_MAX_SECTORS (=1024) in scsi_host_alloc(). I assume no shost dma mapping limit applied.

Then - for example - we could select dev->max_sectors = ATA_MAX_SECTORS_LBA48 (=65535) in ata_dev_configure().

So with commit 0568e6122574 we would have final max sectors = 1024, as opposed to 65535 previously. I guess that the problem is something like this.

If so, it seems that we would need to apply the shost dma mapping limit separately in ata_scsi_dev_config() and not use shost->max_sectors.

thanks,
John




[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux