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. > > 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 Paolo, 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). 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)? Thanks, Bart.��.n��������+%������w��{.n�����{����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
