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

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

[Paolo Valente]

Hi,
this is to retry to request to attend the summit.  This time I'm
trying to propose and agenda topic too.

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.

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.

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".

If needed, I can provide more details on this topic.

As for the expertise that I may bring, I'm somehow expert in:
guaranteeing a good system and application responsiveness (a low lag
in typical Android terminology), providing strong low-latency
guarantees to video/audio playing/streaming applications, guaranteeing
a fair share of the bandwidth, and not just the time, of I/O
resources.

I would like to submit a talk proposal to Vault too.

Thanks,
Paolo

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

[Bart Van Assche]

T24gTW9uLCAyMDE3LTAxLTAyIGF0IDE5OjE0ICswMTAwLCBQYW9sbyBWYWxlbnRlIHdyb3RlOg0K
PiBUaGlzIGlzIHRvIHJldHJ5IHRvIHJlcXVlc3QgdG8gYXR0ZW5kIHRoZSBzdW1taXQuICBUaGlz
IHRpbWUgSSdtDQo+IHRyeWluZyB0byBwcm9wb3NlIGFuZCBhZ2VuZGEgdG9waWMgdG9vLg0KPiAN
Cj4gSSB3b3VsZCBsaWtlIHRvIGF0dGVuZCwgYW5kIHByb3Bvc2UgYSB0b3BpYywgYmVjYXVzZToN
Cj4gMSkgdGhlIHByb2plY3QgZm9yIGFkZGluZyAob25seSkgdGhlIEJGUSBJL08gc2NoZWR1bGVy
IHRvIGJsay1tcSBoYXMNCj4gZW50ZXJlZCBhIHF1aXRlIGFjdGl2ZSBwaGFzZTogdGhlIGZyYW1l
d29yayBwcmVwYXJlZCBieSBKZW5zIHNlZW1zDQo+IG1vc3RseSByZWFkeSBhbmQgY29tcGxldGUs
IGFuZCBJIG5lZWQganVzdCBhIGZldyBkZXRhaWxzIHRvIGNvbXBsZXRlDQo+IHRoZSBwb3J0IG9m
IEJGUS4NCj4gMikgdGhlIGxhbmRpbmcgb2YgQkZRIGludG8gYmxrLW1xIG1pZ2h0IGhhdmUgcG9z
c2libHkgaW1wb3J0YW50DQo+IGNvbnNlcXVlbmNlcywgaW4gYSB3YXkgb3IgdGhlIG90aGVyLg0K
PiANCj4gU28sIGl0IG1pZ2h0IGJlIHF1aXRlIHVzZWZ1bCBmb3IgbWUsIGFuZCBwb3NzaWJseSBm
b3Igb3RoZXINCj4gZGV2ZWxvcGVycy9zdGFrZWhvbGRlcnMgaW50ZXJlc3RlZCBpbiB0aGVzZSBj
aGFuZ2VzIGFuZCBjb25zZXF1ZW5jZXMsDQo+IHRvIGhhdmUgdGhlIG9wcG9ydHVuaXR5IHRvIHRh
bGsgd2l0aCBlYWNoIG90aGVyLCBleGFjdGx5IHdoZW4sIG9yDQo+IHJpZ2h0IGFmdGVyIHRoZXNl
IGNoYW5nZXMgaGFwcGVuLg0KPiANCj4gSW4gYWRkaXRpb24sIGEgZmV3IG1vbnRocyBhZ28gR3Jl
ZyBLSCBhbmQgSmFtZXMgQm90dG9tbGV5IGV2ZW4NCj4gc3VnZ2VzdGVkIHRvIHBvc3Rwb25lIHRv
IHRoaXMgc3VtbWl0LCBvciBWYXVsdCwgdGhlIEtTIGRpc2N1c3Npb24gdGhhdA0KPiBJIHByb3Bv
c2VkIG9uIHRoZSB1bnNvbHZlZCBsYXRlbmN5IHByb2JsZW1zIGZvciB3aGljaCBCRlEgaGFzIGJl
ZW4NCj4gZGV2aXNlZC4gIFNvLCBteSB0b3BpYyBwcm9wb3NhbCB3b3VsZCBiZSBleGFjdGx5IHRo
aXM6DQo+ICJVbnNvbHZlZCBsYXRlbmN5IHByb2JsZW1zLCByZWxhdGVkIHRvIEkvTywgaW4gTGlu
dXg6IGNvbnNlcXVlbmNlcyBvbg0KPiBsc2ItY29tcGxpYW50IGFuZCBBbmRyb2lkIHN5c3RlbXMs
IHNvbHV0aW9ucyBwcm9wb3NlZCBzbyBmYXIsIHBvc3NpYmxlDQo+IG5leHQgc29sdXRpb25zIi4N
Cg0KSGVsbG8gUGFvbG8sDQoNCkkgYWdyZWUgdGhhdCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gZGlz
Y3VzcyBibGstbXEgSS9PIHNjaGVkdWxpbmcgZHVyaW5nDQpMU0YvTU0uIEhvd2V2ZXIsIGJsay1t
cSBJL08gc2NoZWR1bGluZyBpbnZvbHZlcyBtb3JlIHRoYW4gd2hhdCBoYXMgYmVlbg0KZGVzY3Jp
YmVkIGFib3ZlLiBUaGUgdG9waWNzIEkgd291bGQgbGlrZSB0byBzZWUgYmVpbmcgZGlzY3Vzc2Vk
IGFyZToNCiogSG93IHRvIGFkZCBhbiBJL08gc2NoZWR1bGluZyBBUEkgdG8gdGhlIGJsay1tcSBj
b3JlLiBUaGlzIGlzIHdoYXQgSmVucw0KICBpcyB3b3JraW5nIG9uIChodHRwOi8vZ2l0Lmtlcm5l
bC5kay9jZ2l0L2xpbnV4LWJsb2NrL2xvZy8/aD1ibGstbXEtc2NoZWQpLg0KKiBUaGUgQkZRIGZv
ciBibGstbXEgcGF0Y2ggc2VyaWVzIG9uY2UgdGhpcyBwYXRjaCBzZXJpZXMgaGFzIGJlZW4gcG9z
dGVkLg0KICBJZiB0aGUgcnVsZXMgZm9yIHRoaXMgZWRpdGlvbiBvZiBMU0YvTU0gYXJlIHNpbWls
YXIgdG8gdGhvc2Ugb2YgcHJldmlvdXMNCiAgZWRpdGlvbnMgdGhlbiBJIGV4cGVjdCB0aGF0IHRo
ZSBMU0YvTU0gcHJvZ3JhbSBjb21taXR0ZWUgd2lsbCB3YW50IHRvDQogIHNlZSBhIEJGUSBmb3Ig
YmxrLW1xIGltcGxlbWVudGF0aW9uIHBvc3RlZCBhcyBwYXRjaGVzIG9uIGEgTGludXgga2VybmVs
DQogIG1haWxpbmcgbGlzdCBiZWZvcmUgYWRkaW5nIGEgc2Vzc2lvbiBhYm91dCBCRlEgZm9yIGJs
ay1tcSB0byB0aGUgTFNGL01NDQogIGFnZW5kYS4NCiogU2luY2UgQkZRIGhhcyBiZWVuIGRlc2ln
bmVkIGZvciBoYXJkIGRpc2tzIGFuZCBzaW5jZSB0aGUgYXBwcm9hY2ggaW4gQkZRDQogIGZvciBo
YW5kbGluZyBkZWNlcHRpdmUgaWRsZW5lc3MgcmVkdWNlcyBiYW5kd2lkdGgsIHdoYXQgc2NoZWR1
bGluZw0KICBhbGdvcml0aG0gdG8gdXNlIGZvciBzdG9yYWdlIG1lZGlhIHRoYXQgZG8gbm90IGhh
dmUgYW55IG1vdmluZyBwYXJ0cw0KICAoU1NEcyBhbmQgTU1DKS4NCiogSG93IHRvIHBvcnQgdGhl
IE1NQyBkcml2ZXIgdG8gYmxrLW1xLiBTZWUgYWxzbyBMaW51cyBXYWxsZWlqLCAiW1BBVENIDQog
IHYyXSBSRkQ6IHN3aXRjaCBNTUMvU0QgdG8gdXNlIGJsay1tcSBtdWx0aXF1ZXVlaW5nIg0KICAo
aHR0cHM6Ly93d3cuc3Bpbmljcy5uZXQvbGlzdHMvbGludXgtYmxvY2svbXNnMDczNjAuaHRtbCku
DQoNClNvbWV0aGluZyB0aGF0IHdvdWxkIGFsc28gYmUgdXNlZnVsIGlzIHRvIGRlc2NyaWJlIHdo
YXQgeW91IHdvdWxkIGxpa2UgdG8NCmRpc2N1c3MgaW4gYSBzZXNzaW9uIGFib3V0IEJGUSB0aGF0
IGhhcyBub3QgeWV0IGJlZW4gZXhwbGFpbmVkIGluIGFueSBvZg0KdGhlIHBhcGVycyBhYm91dCBC
RlEsIGUuZy4gIkhpZ2ggVGhyb3VnaHB1dCBEaXNrIFNjaGVkdWxpbmcgd2l0aCBGYWlyDQpCYW5k
d2lkdGggRGlzdHJpYnV0aW9uIg0KKGh0dHA6Ly9hbGdvLmluZy51bmltby5pdC9wZW9wbGUvcGFv
bG8vZGlza19zY2hlZC9iZnEtdGVjaHJlcG9ydC5wZGYpPw0KDQpUaGFua3MsDQoNCkJhcnQu

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

[Paolo Valente]

> 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.

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

[Bart Van Assche]

T24gVHVlLCAyMDE3LTAxLTAzIGF0IDEwOjM5ICswMTAwLCBQYW9sbyBWYWxlbnRlIHdyb3RlOg0K
PiBJbiB0aGlzIHJlc3BlY3QsIEkgaG9wZSB0aGF0IHRoZSBjb21taXR0ZWUgZG9lcyBub3QgbWVl
dCB0b28gc29vbi4NCg0KSGVsbG8gUGFvbG8sDQoNCkkgZG9uJ3Qga25vdyB3aGVuIHRoZSBwcm9n
cmFtIGNvbW1pdHRlZSB3aWxsIG1lZXQuIEhvd2V2ZXIsIHdoYXQgSQ0KcmVtZW1iZXIgZnJvbSBw
cmV2aW91cyBlZGl0aW9ucyBvZiB0aGUgTFNGL01NIGlzIHRoYXQgY2hhbmdlcyBvZiB0aGUNCmFn
ZW5kYSBoYXBwZW5lZCBub3Qgb25seSBkdXJpbmcgdGhlIHdlZWtzIGJlZm9yZSB0aGUgTFNGL01N
IGJ1dCBldmVuDQpkdXJpbmcgdGhlIExTRi9NTS4NCg0KQmFydC4=

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

[Paolo Valente]

> Il giorno 03 gen 2017, alle ore 13:00, Bart Van Assche =
<bart.vanassche@sandisk.com> ha scritto:
>=20
> On Tue, 2017-01-03 at 10:39 +0100, Paolo Valente wrote:
>> In this respect, I hope that the committee does not meet too soon.
>=20
> Hello Paolo,
>=20

Hi

> I don't know when the program committee will meet. However, what I
> remember from previous editions of the LSF/MM is that changes of the
> agenda happened not only during the weeks before the LSF/MM but even
> during the LSF/MM.
>=20

That would be perfectly fine.  The only piece of information that I
would need in advance is whether my request to attend is accepted, so
that I can organize my travel and really participate.

Thanks,
Paolo

> Bart.

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

[Jan Kara]

On Tue 03-01-17 18:23:17, Paolo Valente wrote:
> 
> > Il giorno 03 gen 2017, alle ore 13:00, Bart Van Assche <bart.vanassche@sandisk.com> ha scritto:
> > 
> > On Tue, 2017-01-03 at 10:39 +0100, Paolo Valente wrote:
> >> In this respect, I hope that the committee does not meet too soon.
> > 
> > Hello Paolo,
> > 
> 
> Hi
> 
> > I don't know when the program committee will meet. However, what I
> > remember from previous editions of the LSF/MM is that changes of the
> > agenda happened not only during the weeks before the LSF/MM but even
> > during the LSF/MM.
> > 
> 
> That would be perfectly fine.  The only piece of information that I
> would need in advance is whether my request to attend is accepted, so
> that I can organize my travel and really participate.

We certainly notify selected people (and also rejected ones) enough in
advance.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

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

[Bart Van Assche]

T24gVHVlLCAyMDE3LTAxLTAzIGF0IDEwOjM5ICswMTAwLCBQYW9sbyBWYWxlbnRlIHdyb3RlOg0K
PiA+IElsIGdpb3JubyAwMyBnZW4gMjAxNywgYWxsZSBvcmUgMDk6MTcsIEJhcnQgVmFuIEFzc2No
ZSA8QmFydC5WYW5Bc3MNCj4gPiBjaGVAc2FuZGlzay5jb20+IGhhIHNjcml0dG86DQo+ID4gDQo+
ID4gKiBTaW5jZSBCRlEgaGFzIGJlZW4gZGVzaWduZWQgZm9yIGhhcmQgZGlza3MgYW5kIHNpbmNl
IHRoZSBhcHByb2FjaA0KPiA+IGluIEJGUcKgZm9yIGhhbmRsaW5nIGRlY2VwdGl2ZSBpZGxlbmVz
cyByZWR1Y2VzIGJhbmR3aWR0aCwgd2hhdA0KPiA+IHNjaGVkdWxpbmfCoGFsZ29yaXRobSB0byB1
c2UgZm9yIHN0b3JhZ2UgbWVkaWEgdGhhdCBkbyBub3QgaGF2ZSBhbnkNCj4gPiBtb3ZpbmcgcGFy
dHPCoChTU0RzIGFuZCBNTUMpLg0KPiANCj4gSSB3b3VsZCByZWFsbHkgbGlrZSB0byBoYXZlIHRo
ZSBvcHBvcnR1bml0eSB0byBkZWJ1bmsgdGhpcyBmYWxzZQ0KPiBteXRoLiBCRlEgaXMgb3B0aW1p
emVkIGZvciByb3RhdGlvbmFsIGFzIHdlbGwgYXMgbm9uLXJvdGF0aW9uYWwNCj4gZGV2aWNlLsKg
QkZRIGRvZXMgbm90IGtlZXAgdXAgb25seSBpZiBJT1BTIGdvIGJleW9uZCB+NTBrLsKgwqBBbmQg
SSdtDQo+IGFscmVhZHkgd29ya2luZyBvbiB0aGlzIGxpbWl0YXRpb24sIGJ1dCwgYXMgYWdyZWVk
IHdpdGggSmVucywgdGhlDQo+IHByaW9yaXR5IGZvciB0aGUgbW9tZW50IGlzIHB1c2hpbmcgQkZR
IGFzIGl0IGlzLg0KDQpIZWxsbyBQYW9sbywNCg0KQSBxdW90ZSBmcm9tIHRoZSBzZWN0aW9uICJT
ZXJ2aWNlIFByb3BlcnRpZXMiIGZyb20gYSBwYXBlciBmcm9tIDIwMTANCmFib3V0IEJGUTogIklu
IHRoaXMgc2VjdGlvbiB3ZSByZXBvcnQgdGhlIHNlcnZpY2UgcHJvcGVydGllcyBvZiBCRlEsIGlu
DQpib3RoIHNlY3RvciAoYmFuZHdpZHRoIGRpc3RyaWJ1dGlvbikgYW5kIHRpbWUgZG9tYWlucy4g
WyAuLi4gXSBBcyBhDQpjb25zZXF1ZW5jZSwgb25lIHdvdWxkIHNldCBUd2FpdCBhcyBoaWdoIGFz
IHBvc3NpYmxlIHRvIGluY2x1ZGUgYXMgbWFueQ0KYXBwbGljYXRpb25zIGFzIHBvc3NpYmxlLiBI
b3dldmVyLCB0aGUgdmFsdWUgb2YgVHdhaXQgaGFzIGFuIGltcG9ydGFudA0KaW1wYWN0IG9uIHRo
ZSBkaXNrIHRocm91Z2hwdXQuIEl0IG1heSBwcm92aWRlIHNpZ25pZmljYW50IGJvb3N0aW5nIGlu
DQpwcmVzZW5jZSBvZiBkZWNlcHRpdmUgaWRsZW5lc3MsIGJ1dCBvbmx5IGlmIGl0cyB2YWx1ZSBp
cyBpbiB0aGUgb3JkZXINCm9mIHRoZSBzZWVrIGFuZCByb3RhdGlvbmFsIGxhdGVuY2llcyBbMV0s
IG5hbWVseSBhIGZldyBtaWxsaXNlY29uZHMuIEluDQpjb250cmFzdCwgaGlnaGVyIHZhbHVlcyBt
YXkgY2F1c2UgcHJvZ3Jlc3NpdmUgcGVyZm9ybWFuY2UgZGVncmFkYXRpb24sDQphcyB0aGUgZGlz
ayBtYXkgYmUgbGVmdCBpZGxlIGZvciB0b28gbG9uZy4iDQoNCkRpZCBJIHVuZGVyc3RhbmQgY29y
cmVjdGx5IHRoYXQgQkZRIHVzZXMgZGlzayBpZGxpbmcgdG8gaW1wcm92ZQ0Kc2VxdWVudGlhbCBJ
L08gdGhyb3VnaHB1dCBmb3IgaGFyZGRpc2tzPyBJZiBzbywgbXkgcXVlc3Rpb24gaXMgd2h5IHlv
dQ0KdGhpbmsgdGhhdCBkaXNrIGlkbGluZyB3aWxsIG5vdCByZWR1Y2UgdGhyb3VnaHB1dCBmb3Ig
U1NEcyBzaW5jZSBkaXNrDQppZGxpbmcga2VlcHMgdGhlIHF1ZXVlIGRlcHRoIGxvdyB3aGlsZSBT
U0RzIHBlcmZvcm0gYmVzdCBmb3Igd29ya2xvYWRzDQp3aXRoIGEgaGlnaCBxdWV1ZSBkZXB0aD8N
Cg0KVGhhbmtzLA0KDQpCYXJ0Lg==

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

[Paolo Valente]

> Il giorno 08 gen 2017, alle ore 17:30, Bart Van Assche =
<Bart.VanAssche@sandisk.com> ha scritto:
>=20
> On Tue, 2017-01-03 at 10:39 +0100, Paolo Valente wrote:
>>> Il giorno 03 gen 2017, alle ore 09:17, Bart Van Assche <Bart.VanAss
>>> che@sandisk.com> ha scritto:
>>>=20
>>> * 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).
>>=20
>> 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.
>=20
> Hello Paolo,
>=20
> A quote from the section "Service Properties" from a paper from 2010
> about BFQ: "In this section we report the service properties of BFQ, =
in
> both sector (bandwidth distribution) and time domains. [ ... ] As a
> consequence, one would set Twait as high as possible to include as =
many
> applications as possible. However, the value of Twait has an important
> impact on the disk throughput. It may provide significant boosting in
> presence of deceptive idleness, but only if its value is in the order
> of the seek and rotational latencies [1], namely a few milliseconds. =
In
> contrast, higher values may cause progressive performance degradation,
> as the disk may be left idle for too long."
>=20
> Did I understand correctly that BFQ uses disk idling to improve
> sequential I/O throughput for hard disks?

Definitely.

> If so, my question is why you
> think that disk idling will not reduce throughput for SSDs since disk
> idling keeps the queue depth low while SSDs perform best for workloads
> with a high queue depth?
>=20

Because BFQ disables idling for non-rotational devices, especially if
NCQ-capable.  More precisely, on non-rotations devices, BFQ does not
idle to boost throughput, because idling would yield the opposite
result.  Unfortunately, this is one of the small improvements that I
had not the occasion to describe in any paper.  However, you can find
a detailed description of this improvement, in,.e.g., the commit
message for the patch that makes this change within the last BFQ patch
series I have submitted (October 26).  I have pasted this message
below for your convenience.

Thanks,
Paolo

block, bfq: boost the throughput on NCQ-capable flash-based devices

This patch boosts the throughput on NCQ-capable flash-based devices,
while still preserving latency guarantees for interactive and soft
real-time applications. The throughput is boosted by just not idling
the device when the in-service queue remains empty, even if the queue
is sync and has a non-null idle window. This helps to keep the drive's
internal queue full, which is necessary to achieve maximum
performance. This solution to boost the throughput is a port of
commits a68bbdd and f7d7b7a for CFQ.

As already highlighted in a previous patch, allowing the device to
prefetch and internally reorder requests trivially causes loss of
control on the request service order, and hence on service guarantees.
Fortunately, as discussed in detail in the comments on the function
bfq_bfqq_may_idle(), if every process has to receive the same
fraction of the throughput, then the service order enforced by the
internal scheduler of a flash-based device is relatively close to that
enforced by BFQ. In particular, it is close enough to let service
guarantees be substantially preserved.

Things change in an asymmetric scenario, i.e., if not every process
has to receive the same fraction of the throughput. In this case, to
guarantee the desired throughput distribution, the device must be
prevented from prefetching requests. This is exactly what this patch
does in asymmetric scenarios.


> Thanks,
>=20
> Bart.

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

[Ulf Hansson]

[...]

>
> 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. The topics I would like to see being discussed are:
> * 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=blk-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.
> * 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).
> * 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).

Hi Bart,

As the MMC maintainer I am also interested in participating in all the
above BFQ/MMC related discussions.

Regarding the blk-mq port for MMC, I would also like to add a detail,
which perhaps may influence the generic blkmq interface.

The MMC block device driver implements a asynchronous request
mechanism, which increases performance for architectures where DMA
mapping operations are slow (cache flushes/bounce buffering when using
non-coherent DMAs). Ideally I would like to remove this hack from the
MMC subsystem, if it makes sense to extend blkmq to support this. And
if not, perhaps we can discuss on the best method to implement it for
MMC.

Kind regards
Uffe

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

[Adam Manzanares]

The 01/02/2017 19:14, Paolo Valente wrote:
> Hi,
> this is to retry to request to attend the summit.  This time I'm
> trying to propose and agenda topic too.
> 
> 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.
> 
> 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.
> 
> 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".

Hello,

We are also interested in the unsolved latency problems. In 4.10 we got 
some patches merged that deal with iopriority being passed from the 
application to device drivers that send commands to SATA HDDs. This allows an 
application to achieve better tail latencies for prioritized workloads 
when queuing is enabled at the device. 

We would like to discuss the implications of adapting this work to block-mq 
and BFQ. In addition we would like to discuss potential applications and 
devices (including device driver changes) that would benefit from having 
iopriority information.

Thanks,
Adam 

> 
> If needed, I can provide more details on this topic.
> 
> As for the expertise that I may bring, I'm somehow expert in:
> guaranteeing a good system and application responsiveness (a low lag
> in typical Android terminology), providing strong low-latency
> guarantees to video/audio playing/streaming applications, guaranteeing
> a fair share of the bandwidth, and not just the time, of I/O
> resources.
> 
> I would like to submit a talk proposal to Vault too.
> 
> Thanks,
> Paolo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-block" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html