> On 13.07.2016, at 13:07, Mike Belopuhov <m...@belopuhov.com> wrote: > > On Wed, Jul 13, 2016 at 12:48 +0200, Peter N. M. Hansteen wrote: >> On Wed, Jul 13, 2016 at 12:39:14PM +0200, Christian R????ner wrote: >>>> Hello, you should use virtio drivers for the disk in KVM. >>> >>> I already use virtio ;-) But there is no need for the BSD kernel to do further >>> scheduling. >> >> I'm not at all there is a knob to twiddle here, but if there is, will you >> realistically see any difference in performance (assuming this is about >> shaving cycles off)? >> > > Christian has a point, there's no need to involve the default block > number oriented elevator (nscan) for devices that don't care about > this. > > Unfortunately, as it stands the NOOP elevator (called FIFO in OpenBSD) > will only be used by disks properly advertising SCSI Thin Provisioning > support like this SSD for example: > > sd0 at scsibus1 targ 0 lun 0: <ATA, Samsung SSD 850, EXM0> SCSI3 0/direct fixed naa.50025388a08facb7 > sd0: 244198MB, 512 bytes/sector, 500118192 sectors, thin > > The controller in question (vioblk) must fake those SCSI pages to let > sd(4) driver query them and select FIFO scheduler. It's not doing it > at the moment. > > It's possible to change the default disk elevator to FIFO by changing > BUFQ_DEFAULT define in /sys/sys/buf.h to BUFQ_FIFO and recompile the > kernel. There's no way to change it in the runtime. > > I would argue that instead of faking SCSI pages, it must be possible > for the controller to hint sd(4) drivers that FIFO scheduling is > preferred. >
And it is not just about virtual disks, nvme(4) suffers from the same problem: sd0 at scsibus1 targ 0 lun 0: <NVMe, SAMSUNG MZVKV512, 6L0Q> SCSI4 0/direct fixed sd0: 488386MB, 512 bytes/sector, 1000215217 sectors This NVMe disk uses nscan because it doesn't advertise "thin". To be fair, the driver is new and dlg@ knows about it. Reyk
