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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
