Re: [LSF/MM ATTEND AND AGENDA TOPIC] request to attend the summit

[Paolo Valente <paolo.valente@linaro.org>]

> Il giorno 03 gen 2017, alle ore 09:17, Bart Van Assche =
<Bart.VanAssche@sandisk.com> ha scritto:
>=20
> On Mon, 2017-01-02 at 19:14 +0100, Paolo Valente wrote:
>> This is to retry to request to attend the summit.  This time I'm
>> trying to propose and agenda topic too.
>>=20
>> I would like to attend, and propose a topic, because:
>> 1) the project for adding (only) the BFQ I/O scheduler to blk-mq has
>> entered a quite active phase: the framework prepared by Jens seems
>> mostly ready and complete, and I need just a few details to complete
>> the port of BFQ.
>> 2) the landing of BFQ into blk-mq might have possibly important
>> consequences, in a way or the other.
>>=20
>> So, it might be quite useful for me, and possibly for other
>> developers/stakeholders interested in these changes and consequences,
>> to have the opportunity to talk with each other, exactly when, or
>> right after these changes happen.
>>=20
>> In addition, a few months ago Greg KH and James Bottomley even
>> suggested to postpone to this summit, or Vault, the KS discussion =
that
>> I proposed on the unsolved latency problems for which BFQ has been
>> devised.  So, my topic proposal would be exactly this:
>> "Unsolved latency problems, related to I/O, in Linux: consequences on
>> lsb-compliant and Android systems, solutions proposed so far, =
possible
>> next solutions".
>=20
> Hello Paolo,
>=20

Hi Bart

> I agree that it would be useful to discuss blk-mq I/O scheduling =
during
> LSF/MM. However, blk-mq I/O scheduling involves more than what has =
been
> described above.

Definitely.

> The topics I would like to see being discussed are:

I agree on discussing all the points you mention. Some details below.

> * How to add an I/O scheduling API to the blk-mq core. This is what =
Jens
>  is working on =
(http://git.kernel.dk/cgit/linux-block/log/?h=3Dblk-mq-sched).
> * The BFQ for blk-mq patch series once this patch series has been =
posted.
>  If the rules for this edition of LSF/MM are similar to those of =
previous
>  editions then I expect that the LSF/MM program committee will want to
>  see a BFQ for blk-mq implementation posted as patches on a Linux =
kernel
>  mailing list before adding a session about BFQ for blk-mq to the =
LSF/MM
>  agenda.

In this respect, I hope that the committee does not meet too soon.
I'm waiting just for some replies from Jens to complete a first,
postable patch series.  Anyway, even if no patch series is available
yet, I hope it is clear that we are well on the way.  Probably a
matter of one month at most ...

> * Since BFQ has been designed for hard disks and since the approach in =
BFQ
>  for handling deceptive idleness reduces bandwidth, what scheduling
>  algorithm to use for storage media that do not have any moving parts
>  (SSDs and MMC).

I would really like to have the opportunity to debunk this false myth.
BFQ is optimized for rotational as well as non-rotational device.  BFQ
does not keep up only if IOPS go beyond ~50k.  And I'm already
working on this limitation, but, as agreed with Jens, the priority for
the moment is pushing BFQ as it is.

> * How to port the MMC driver to blk-mq. See also Linus Walleij, =
"[PATCH
>  v2] RFD: switch MMC/SD to use blk-mq multiqueueing"
>  (https://www.spinics.net/lists/linux-block/msg07360.html).
>=20
> Something that would also be useful is to describe what you would like =
to
> discuss in a session about BFQ that has not yet been explained in any =
of
> the papers about BFQ, e.g. "High Throughput Disk Scheduling with Fair
> Bandwidth Distribution"
> (http://algo.ing.unimo.it/people/paolo/disk_sched/bfq-techreport.pdf)?
>=20

Yes, I would really like to share the additional ideas that I put in
BFQ.  In fact, for me BFQ is more a collection of ideas than a
monolithic object.  Some of the components I would like to talk about
are, e.g., the automatic detection of soft real-time applications, and
the use of preemption to boost throughput without breaking bandwidth
and latency guarantees.

Thanks,
Paolo

> Thanks,
>=20
> Bart.