> Il giorno 13 mag 2017, alle ore 09:50, Sedat Dilek <sedat.dilek@xxxxxxxxx> ha scritto: > > On Wed, May 3, 2017 at 11:21 AM, Paolo Valente <paolo.valente@xxxxxxxxxx> wrote: >> >>> Il giorno 03 mag 2017, alle ore 10:00, Sedat Dilek <sedat.dilek@xxxxxxxxx> ha scritto: >>> >>> On Tue, May 2, 2017 at 2:16 PM, Markus Trippelsdorf >>> <markus@xxxxxxxxxxxxxxx> wrote: >>>> On 2017.05.02 at 14:07 +0200, Sedat Dilek wrote: >>>>> On Tue, May 2, 2017 at 10:00 AM, Markus Trippelsdorf >>>>> <markus@xxxxxxxxxxxxxxx> wrote: >>>>>> On 2017.05.02 at 09:54 +0200, Sedat Dilek wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I want to play with BFQ. >>>>>>> >>>>>>> My base is block-next as of 28-Apr-2017. >>>>> [...] >>>>>>> Not sure if the attached patches make sense (right now). >>>>>> >>>>>> No, it doesn't make sense at all. >>>>> >>>>> Hmm, I looked at 4.11.0-v8r11 and 0001 has exactly what my 2 patches do :-). >>>> >>>> BFQ started as a conventional scheduler. But because mq is the way of >>>> the future it was ported before it was accepted into mainline. >>>> >>> >>> I am still playing and want to do my own experiences with BFQ. >>> >>> Not sure if FIO is a good testcase-tool here. >>> >> >> If you want to perform a thorough benchmarking of also responsiveness >> and latency for time-sensitive applications (such as video playing) >> then you may want to use S [1]. It's rather rustic, do ask if you >> encounter any difficulty. >> >> [1] https://github.com/Algodev-github/S >> > > Sorry for the delay. Don't worry, I'm replying late too ... > Currently, I am swittching from Ubuntu/precise 12.04 LTS (EOL) back to > the Debian world. > > The responsiveness is really bad when my mlocate cron-job, a git pull > on linux.git and firefox runs parallel. Thanks for reporting this issue. I have a few considerations and requests for information on it. 1) Two of the three sources of I/O you mention, namely mlocate update and git pull, are doing writes. As I already pointed in a few occasions and places, intense write workloads trigger problems that an I/O scheduler cannot solve. In contrast, these problems *can* be solved using BFQ. In particular, I already have a prototype solution, but I have't found support yet to turn it into a possible production-level solution; till a few days, ago, when I talked about this with Goldwyn Rodrigues (in CC). He seems interested in having a look at this solution, and possibly collaborating on it. 2) A web browser like Firefox can generate extremely varying workloads; so, if you mentioned Firefox as one of the sources of I/O in your unlucky situation, then it would be important to know what Firefox was doing. 3) Even if BFQ cannot counteract problems occurring above its head, it usually improves responsiveness even in heavy-write scenarios. It would then be interesting if you could compare responsiveness with the other I/O schedulers (mq-deadline, Kyber) and with none too (make sure that the I/O is really the same in all cases). > This is with Linux v4.11.1-rc1 and BFQ patchset v4.11.0-v8r11. > > My linux-config is attached. > >>> So if MQ is the way why isn't the Kconfig called CONFIG_MQ_IOSCHED_BFQ >>> according to CONFIG_MQ_IOSCHED_DEADLINE? >>> >>> As we are talking about "*Storage* I/O schedulers" which of the MQ >>> Kconfig make sense when using MQ_DEADLINE and (MQ_)BFQ? >>> >>> # egrep -i 'bfq|deadline|_mq|mq_|_mq_' /boot/config-4.11.0-1-bfq-amd64 >>> CONFIG_POSIX_MQUEUE=y >>> CONFIG_POSIX_MQUEUE_SYSCTL=y >>> CONFIG_BLK_WBT_MQ=y >>> CONFIG_BLK_MQ_PCI=y >>> CONFIG_BLK_MQ_VIRTIO=y >>> CONFIG_IOSCHED_DEADLINE=y >>> CONFIG_IOSCHED_BFQ=y >>> CONFIG_BFQ_GROUP_IOSCHED=y >>> # CONFIG_DEFAULT_DEADLINE is not set >>> CONFIG_DEFAULT_BFQ=y >>> CONFIG_DEFAULT_IOSCHED="bfq" >>> CONFIG_MQ_IOSCHED_DEADLINE=y >>> # CONFIG_NET_SCH_MQPRIO is not set >>> CONFIG_SCSI_MQ_DEFAULT=y >>> # CONFIG_DM_MQ_DEFAULT is not set >>> >> >> The config for BFQ seems correct. For the others, it depends on what >> scheduler you want. If useful for you, the other two MQ- schedulers >> are mq-deadline and cyber. >> > > What about those two (Kconfig) patches which is in your current > bfq-4.11.y patchset. > I'm not sure I fully understand the purpose of the two patches you propose (in your following emails). The first patch seems to move BFQ config options to a different position in Kconfig.iosched, but the position of those items should be irrelevant. Am I missing something? The second patch seems to have to do with configuration bits of bfq for blk, yet such a bfq version is not available in mainline. In any case, for possible new submissions, you should inline your patches. For complete instructions on submitting patches, have a look at Documentation/process/submitting-patches Thanks, Paolo > Thanks Sedat. > <config-4.11.1-rc1-1-iniza-amd64>
