Re: [Qemu-discuss] virtio-scsi really slow init with ArchLinux kernel

[Dongli Zhang]

While there is no delay with stable 4.7.15 kernel, there is a delay less than 8
seconds with ubuntu ppa kernel 4.7.15 on amd64. Perhaps this is related to
kernel config file, as I used "make defconfig" with scsi virtio enabled 
manually.

[    0.905328] scsi host2: Virtio SCSI HBA
[    0.905810] scsi 2:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+
PQ: 0 ANSI: 5
[    0.912323] FDC 0 is a S82078B
[    0.927547] PCI Interrupt Link [LNKC] enabled at IRQ 10
[    1.250295] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 52:54:00:12:34:56
[    1.250452] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection
[    1.251320] e1000 0000:00:03.0 ens3: renamed from eth0
[    1.600095] tsc: Refined TSC clocksource calibration: 3392.142 MHz
[    1.600250] clocksource: tsc: mask: 0xffffffffffffffff max_cycles:
0x30e54fbd081, max_idle_ns: 440795321209 ns
[    7.696221] random: fast init done
[    9.264477] sd 2:0:0:0: Power-on or device reset occurred
[    9.264743] sd 2:0:0:0: Attached scsi generic sg1 type 0
[    9.265183] sd 2:0:0:0: [sda] 62914560 512-byte logical blocks: (32.2 GB/30.0
GiB)
[    9.265460] sd 2:0:0:0: [sda] Write Protect is off
[    9.265576] sd 2:0:0:0: [sda] Mode Sense: 63 00 00 08
[    9.265656] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[    9.266258]  sda: sda1
[    9.266638] sd 2:0:0:0: [sda] Attached SCSI disk


Dongli Zhang

On 07/12/2018 01:35 PM, Dongli Zhang wrote:
> Hi Chris,
> 
> On 07/12/2018 01:45 AM, Chris wrote:
>> On Wed, Jul 11, 2018 at 12:43 PM, Greg Kurz <address@hidden> wrote:
>>> I've been observing a similar delay on ppc64 with fedora28 guests:
>>>
>>> # dmesg | egrep 'scsi| sd '
>>> [    1.530946] scsi host0: Virtio SCSI HBA
>>> [    1.532452] scsi 0:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    
>>> 2.5+ PQ: 0 ANSI: 5
>>> [   21.928378] sd 0:0:0:0: Power-on or device reset occurred
>>> [   21.930012] sd 0:0:0:0: Attached scsi generic sg0 type 0
>>> [   21.931554] sd 0:0:0:0: [sda] 83886080 512-byte logical blocks: (42.9 
>>> GB/40.0 GiB)
>>> [   21.931929] sd 0:0:0:0: [sda] Write Protect is off
>>> [   21.933110] sd 0:0:0:0: [sda] Mode Sense: 63 00 00 08
>>> [   21.934084] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
>>> doesn't support DPO or FUA
>>> [   21.943566] sd 0:0:0:0: [sda] Attached SCSI disk
>>>
>>> Kernel version is 4.16.16-300.fc28.ppc64. And I cannot reproduce the
>>> issue with other distros that have an older kernel, eg, ubuntu 18.04
>>> with kernel 4.15.0-23-generic.
>>>
>>> My first guess is that it might be a kernel-side regression introduced
>>> in 4.16... maybe bisect ?
>>
>> Interesting. I just tried kernel 4.17.5 from the mainline ppa on
>> Ubuntu 18.04 and now there is a delay. It's only 7.5 seconds but still
>> noticeable. There was previously no delay with the 4.15 kernel.
> 
> I did not observe any delay with stable 4.17.5 on ubuntu 18.04 (I built the
> kernel myself with CONFIG_SCSI_VIRTIO=y):
> 
> # qemu-system-x86_64 -drive
> file=/home/zhang/img/ubuntu1804.qcow2,format=qcow2,if=none,id=virt1 -device
> virtio-scsi-pci,id=virt1 -device scsi-hd,drive=virt1 -m 4096M -enable-kvm 
> -smp 6
> -net nic -net user,hostfwd=tcp::5022-:22 -kernel
> /home/zhang/test/linux-4.17.5/arch/x86_64/boot/bzImage -append "root=/dev/sda1
> init=/sbin/init text" -enable-kvm
> 
> 
> # uname -r
> 4.17.5
> 
> [0.190434] scsi host0: Virtio SCSI HBA
> [0.190924] scsi 0:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    2.5+ PQ: > 0
> ANSI: 5
> [0.206282] random: fast init done
> [0.216651] sd 0:0:0:0: Power-on or device reset occurred
> [0.216907] sd 0:0:0:0: Attached scsi generic sg0 type 0
> [0.217207] ata_piix 0000:00:01.1: version 2.13
> [0.217613] sd 0:0:0:0: [sda] 62914560 512-byte logical blocks: (32.2 GB/30.0 
> GiB)
> [0.217959] sd 0:0:0:0: [sda] Write Protect is off
> [0.218152] sd 0:0:0:0: [sda] Mode Sense: 63 00 00 08
> [0.218193] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
> doesn't
> support DPO or FUA
> 
> 
> In addition, I could not reproduce with '4.18-rc4' or 'v4.17-rc7'.
> 
> 
> Dongli Zhang
> 
>>
>> Definitely seems like it could be something introduced in kernel 4.16.
>>
>> Chris
>>
>