From owner-svn-src-all@freebsd.org Tue Dec 31 11:54:21 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4E85E1D2566; Tue, 31 Dec 2019 11:54:21 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47nCQ51CZDz4C9n; Tue, 31 Dec 2019 11:54:21 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 22C568E38; Tue, 31 Dec 2019 11:54:21 +0000 (UTC) Date: Tue, 31 Dec 2019 11:54:21 +0000 From: Alexey Dokuchaev To: Alexander Motin Cc: Warner Losh , src-committers , 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> References: <201912292116.xBTLG4kV012809@repo.freebsd.org> <20191230113243.GA58338@FreeBSD.org> <20191230170208.GA20424@FreeBSD.org> <5a97d344-8741-3b8e-b6dd-b8e4cfa05aeb@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5a97d344-8741-3b8e-b6dd-b8e4cfa05aeb@FreeBSD.org> User-Agent: Mutt/1.11.4 (2019-03-13) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 11:54:21 -0000 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