Date: Fri, 27 Dec 2019 12:49:04 -0700 From: Warner Losh <imp@bsdimp.com> To: Alexander Motin <mav@freebsd.org> Cc: "freebsd-geom@FreeBSD.org" <freebsd-geom@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, Warner Losh <imp@freebsd.org>, Luigi Rizzo <luigi@freebsd.org>, "Andrey V. Elsukov" <ae@freebsd.org>, Pawel Jakub Dawidek <pjd@freebsd.org>, "Conrad E. Meyer" <cem@freebsd.org> Subject: Re: gsched: modernize or remove? Message-ID: <CANCZdfovCe1UQmC%2B94QK5P-imLEBygoyQLDqNSdDPeYryoL=bA@mail.gmail.com> In-Reply-To: <6d466360-988f-e80d-3212-b6c479a5ec03@FreeBSD.org> References: <6d466360-988f-e80d-3212-b6c479a5ec03@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 27, 2019 at 10:53 AM Alexander Motin <mav@freebsd.org> wrote: > Hi, > > As I can see, gsched code was not really maintained for the last 10 > years since being added. It misses many GEOM features added later, such > as direct dispatch, unmapped I/O, stripesize/stripeoffset, resize, etc. > Even if some of them may require just a proper declaration, it tells me > that barely anybody used it seriously for years. But my primary concern > is the `gsched insert` implementation. Right now I got to it since it > is the last consumer of nstart/nend counters in GEOM, which I would like > to remove for performance reasons. But I also see tons of potential > problems with idea of moving providers between unaware geoms. > > So my question is: does it make sense to try fix/modernize it, or it > just be easier to remove it? Does anybody still use it, or see some > future for it? While it's kinda cool, I'm not sure it has stayed relevant enough. It's kinda at the wrong layer to do effective scheduling since the low level drivers get to pick and choose what goes to the drive when. We had a lot better luck tweaking performance doing this at the bottom of CAM. We've noticed that we like could do a bit better if we can have more coordination with the upper layers. We've not done a lot there yet, but it seems like gsched is in the middle and has the worst of both worlds: it's too low in the stack to control pacing from the upper layers, and it's too high in the stack to effectively control doling out the I/O operations to the device. So I think I'm more on the 'remove' side than the 'improve' side of your question. I wouldn't oppose someone doing a lot of work here if their workload benefits better from it, but I don't think we should do it just because we have it in the tree. It's getting in the way, so my bias is towards removal. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfovCe1UQmC%2B94QK5P-imLEBygoyQLDqNSdDPeYryoL=bA>