Date: Tue, 31 Dec 2019 11:54:21 +0000 From: Alexey Dokuchaev <danfe@freebsd.org> To: Alexander Motin <mav@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r356185 - in head: lib/geom lib/geom/sched sys/geom sys/geom/sched sys/modules/geom sys/modules/geom/geom_sched sys/sys Message-ID: <20191231115421.GA41351@FreeBSD.org> In-Reply-To: <5a97d344-8741-3b8e-b6dd-b8e4cfa05aeb@FreeBSD.org> References: <201912292116.xBTLG4kV012809@repo.freebsd.org> <20191230113243.GA58338@FreeBSD.org> <CANCZdfq-BGXpeUHpC1MLH2kfjHvkmB8VKuGsQX6=P9EsGs=LPA@mail.gmail.com> <20191230170208.GA20424@FreeBSD.org> <5a97d344-8741-3b8e-b6dd-b8e4cfa05aeb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 30, 2019 at 02:55:16PM -0500, Alexander Motin wrote: > On 30.12.2019 12:02, Alexey Dokuchaev wrote: > > ... > > Well, hard drives essentially didn't change since then, still being > > the same rotation media. :) > > At least some papers about gsched I read mention adX devices, which > means old ATA stack and no NCQ. It can be quite a significant change to > let HDD to do its own scheduling. Also about a year ago in r335066 > Warner added sysctl debug.bioq_batchsize, which if set to non-zero value > may, I think, improve fairness between several processes, just not sure > why it was never enabled. Thanks for the pointer, I'll remember to play with it. > > Admittedly, I've only did some tests no later than in 8.4 times when I > > first started using it. Fair point, though, I should redo them again. > > I'm sorry to create a regression for you, if there is really one. As I > have written I don't have so much against the scheduler part itself, as > against the accumulated technical debt and the way integration is done, > such as mechanism of live insertion, etc. Without unmapped I/O and > direct dispatch I bet it must be quite slow on bigger systems, that is > why I doubted anybody really use it. It's OK, no need to be sorry, I understand the reasons behind the move and it certainly looks justified enough. > > Is there a planned replacement, or I'd better create a port for the > > GEOM_SCHED class and gsched(8) tool? > > I wasn't planning replacement. And moving it to ports would be a > problem, since in process I removed few capabilities critical for it: > nstart/nend for live insertion and BIO classification for scheduling. > But the last I don't mind to return if there appear to be a need. It > is only the first I am strongly against. But if somebody would like to > reimplement it, may be it would be better to consider merging it with > CAM I/O scheduler by Warner? The one at least knows about device queue > depth, etc. We could return the BIO classification to be used by CAM > scheduler instead, if needed. Make sense; thanks everyone who replied in the thread, it was quite fruitful. ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191231115421.GA41351>