> Il giorno 16 mag 2017, alle ore 15:22, Sedat Dilek <sedat.di...@gmail.com> ha > scritto: > > On Tue, May 16, 2017 at 10:45 AM, Paolo Valente > <paolo.vale...@linaro.org> wrote: >> >>> Il giorno 13 mag 2017, alle ore 09:50, Sedat Dilek <sedat.di...@gmail.com> >>> ha scritto: >>> >>> On Wed, May 3, 2017 at 11:21 AM, Paolo Valente <paolo.vale...@linaro.org> >>> wrote: >>>> >>>>> Il giorno 03 mag 2017, alle ore 10:00, Sedat Dilek >>>>> <sedat.di...@gmail.com> ha scritto: >>>>> >>>>> On Tue, May 2, 2017 at 2:16 PM, Markus Trippelsdorf >>>>> <mar...@trippelsdorf.de> wrote: >>>>>> On 2017.05.02 at 14:07 +0200, Sedat Dilek wrote: >>>>>>> On Tue, May 2, 2017 at 10:00 AM, Markus Trippelsdorf >>>>>>> <mar...@trippelsdorf.de> 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). >> > > Not willing to test on this dead horse called Ubuntu 12.04. > >> >>> 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 >> > > All my testings was done with your patchset against Linux v4.11.y. > You have the same kconfig/kbuild stuff in your 0001 patch [1], so :-)? > What you have in 0001 is missing in Linux v4.12-rc1. > Not sure if this is intended.
4.12-rc1 contains bfq for blk-mq, while the patch you mention is for bfq for blk (never accepted in mainline). Maybe you could get a clearer idea by having a look at the commits that add bfq (for blk-mq) in 4.12-rc1. Hope this helps, Paolo > I will re-submit and add a "4.12" in the subject-line when I am at home. > > - Sedat - > > [1] > http://algo.ing.unimo.it/people/paolo/disk_sched/patches/4.11.0-v8r11/0001-block-cgroups-kconfig-build-bits-for-BFQ-v7r11-4.11..patch
