Date: Mon, 30 Dec 2019 14:01:04 -0700 From: Warner Losh <imp@bsdimp.com> To: Alexander Motin <mav@freebsd.org> Cc: Alexey Dokuchaev <danfe@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <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: <CANCZdfoWiD9zsBJE8U%2BPM5LyLSKLgQu9m2pvdkUFbuccv_q-Qg@mail.gmail.com> 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 12:55 PM Alexander Motin <mav@freebsd.org> wrote: > 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. > I never enabled it because I never had a good car size as the default. I'm guessing it's somewhere on the order of 2 times the queue size in hardware, but with modern drives I think phk might be right and that disabling disksort entirely might be optimal, or close to optimal. > >> 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. > I'd be keen on helping anybody that wants to experiment with hard disk drive optmizations in iosched. My doodles to make it better showed no early improvements, so Iv'e not tried to bring them into the tree. However, our workload is basically 'large block random' which isn't the same as others and others might have a workload that could benefit. I've found a marginal improvement from the read over writes bias in our workload, and another marginal improvement for favoring metadata reads over normal reads (because for us, sendfile blocks for some of these reads, but others may see no improvement). I'm working to clean up the metadata read stuff to get it into the tree. I've not tested it on ZFS, though, so there will be no ZFS metadata labeling in the initial commit. So I like the idea, and would love to work with someone that needs it and/or whose work loads can be improved by it. Warner -- > Alexander Motin >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoWiD9zsBJE8U%2BPM5LyLSKLgQu9m2pvdkUFbuccv_q-Qg>