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

[Alexander Motin]

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