Hi all,

I've now committed the current state of my work to master. The 'fq' policy
should still be considered experimental and hence isn't active by default.
The rest of this mail is basically some notes put together from my previous
2 or 3 mails, so that they are all in one place. If there's something
missing, let me know.

Just to emphasize this: the default noop policy should have no visible
effect on the performance when compared to before these commits and is the
default choice. If you feel more adventurous, you can enable the
*EXPERIMENTAL* fq (fair queuing) policy as outlined below. It should give
you major improvements in concurrent I/Os, especially in read latency.

Let me know how it works out for you and suggestions on how to improve it.
The next few weeks I'll have somewhat more limited time again due to exams
coming up, but I'll try to be responsive.

The fq policy has a bunch of XXX in the code that could/would improve
performance and fairness, and I hope to address them over time, however most
of them are no priority. You could also take this opportunity and write your
own scheduling policy; either from scratch or by using dsched_fq as a base,
as it quite nicely tracks all processes/threads/bufs in the system as is
required for most modern I/O scheduling policies.

--

The work basically consists of 4 parts:
- General system interfacing
- I/O scheduler framework (dsched)
- I/O scheduler fair queuing policy (dsched_fq or fq)
- userland tools (dschedctl and ionice)

--

By default you still won't notice any difference, as the default scheduler
is the so-called noop (no operation) scheduler; it emulates our previous
behaviour. This can be confirmed by dschedctl -l:
# dschedctl -l
cd0     =>      noop
da0     =>      noop
acd0    =>      noop
ad0     =>      noop
fd0     =>      noop
md0     =>      noop

--

To enable the fq policy on a disk you have two options:

1) set dsched_pol_{diskname}="fq" in /boot/loader.conf; e.g. if it should ...
[ message continues ]

I'm still of the opinion that having a tool that resembles "nice" that 
closely having the exact opposite semantics is a really bad idea.  People 
*will* forget which is what, and mess it up, especially users that are new 
to the whole Unix thing.


If it for some reason is absolutely imperative that the numerical 
interpretation of the priority levels don't change (I don't see why, but 
you might have your reasons), would you consider renaming the tool 
"iopriority" or something similar?

(I would still prefer that it works exactly as "nice" with no surprises, 
negative levels and all, but a different name would hopefully serve to 
remind users that the two really are different.)


MAgnus

[ message continues ]

I agree and I haven't forgotten about it. It's just that I'm quite busy with
real life and the little time I got I try to spend it on what I consider
more important things.

Eventually I'll rename ionice to ioprio; it should make more sense to
people. Anyways, thanks for the reminder. Oh, and if anyone else with a
commit bit feels like it, just go ahead and do the rename :)

Cheers,
Alex Hornung

[ message continues ]

I'm still of the opinion that having a tool that resembles "idprio" and 
"rtprio" that closely having the exact opposite semantics is a really 
bad idea.  People *will* forget which is what, and mess it up, 
especially users that are new to the whole Unix thing.

(I would still prefer that it works exactly as "nice" with no surprises, 
negative levels and all, but a different name would hopefully serve to 
remind users that the two really are different.)

- Chris [1]

.. [1] text heavily borrowed from magnus

[ message continues ]