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

[Alexey Dokuchaev]

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