Date: Mon, 30 Dec 2019 14:55:16 -0500 From: Alexander Motin <mav@FreeBSD.org> To: Alexey Dokuchaev <danfe@freebsd.org>, Warner Losh <imp@bsdimp.com> Cc: 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: <5a97d344-8741-3b8e-b6dd-b8e4cfa05aeb@FreeBSD.org> In-Reply-To: <20191230170208.GA20424@FreeBSD.org> References: <201912292116.xBTLG4kV012809@repo.freebsd.org> <20191230113243.GA58338@FreeBSD.org> <CANCZdfq-BGXpeUHpC1MLH2kfjHvkmB8VKuGsQX6=P9EsGs=LPA@mail.gmail.com> <20191230170208.GA20424@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30.12.2019 12:02, Alexey Dokuchaev wrote: > On Mon, Dec 30, 2019 at 08:55:14AM -0700, Warner Losh wrote: >> On Mon, Dec 30, 2019, 5:32 AM Alexey Dokuchaev wrote: >>> On Sun, Dec 29, 2019 at 09:16:04PM +0000, Alexander Motin wrote: >>>> New Revision: 356185 >>>> URL: https://svnweb.freebsd.org/changeset/base/356185 >>>> >>>> Log: >>>> Remove GEOM_SCHED class and gsched tool. >>>> [...] >>> >>> Wow, that was unexpected, I use it on all my machines' HDD drives. >>> Is there a planned replacement, or I'd better create a port for the >>> GEOM_SCHED class and gsched(8) tool? >> >> How much of a performance improvement do you see with it? >> >> There has been no tweaks to this geom in years and years. It was tuned >> to 10 year old hard drives and never retuned for anything newer. > > Well, hard drives essentially didn't change since then, still being the > same roration 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. >> And when I played with it a few years ago, I saw no improvements... > > 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. > 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. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5a97d344-8741-3b8e-b6dd-b8e4cfa05aeb>