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