| Message ID | CA+icZUV8wEKJkDpfMaPhAyc1fyVG-ViZF4nO=5raZOkLa_ikzQ@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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. > > First I looked through the Kconfigs. > What is a good setting? > Built as module? > > How can I switch the IO-scheduler - real-time? > > Not sure if the attached patches make sense (right now). No, it doesn't make sense at all. BFQ is a mq scheduler. To use it you should enable SCSI_MQ_DEFAULT. And then you can switch schedulers like: echo "kyber" > /sys/block/sda/queue/scheduler echo "bfq" > /sys/block/sdb/queue/scheduler
On Tue, May 2, 2017 at 10:00 AM, Markus Trippelsdorf <markus@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. >> >> First I looked through the Kconfigs. >> What is a good setting? >> Built as module? >> >> How can I switch the IO-scheduler - real-time? >> >> Not sure if the attached patches make sense (right now). > > No, it doesn't make sense at all. > BFQ is a mq scheduler. To use it you should enable > SCSI_MQ_DEFAULT. And then you can switch schedulers like: > > echo "kyber" > /sys/block/sda/queue/scheduler > echo "bfq" > /sys/block/sdb/queue/scheduler > Great, I got these informations before starting a kernel-build. So, I have now... $ ./scripts/diffconfig /boot/config-4.11.0-1-iniza-amd64 .config -BLK_DEV_HD n SCSI_MQ_DEFAULT n -> y +BFQ_GROUP_IOSCHED y +BLK_DEV_THROTTLING_LOW n +IOSCHED_BFQ y +MQ_IOSCHED_KYBER y Thanks, Markus. - Sedat -
On Tue, May 2, 2017 at 10:07 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote: > On Tue, May 2, 2017 at 10:00 AM, Markus Trippelsdorf > <markus@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. >>> >>> First I looked through the Kconfigs. >>> What is a good setting? >>> Built as module? >>> >>> How can I switch the IO-scheduler - real-time? >>> >>> Not sure if the attached patches make sense (right now). >> >> No, it doesn't make sense at all. >> BFQ is a mq scheduler. To use it you should enable >> SCSI_MQ_DEFAULT. And then you can switch schedulers like: >> >> echo "kyber" > /sys/block/sda/queue/scheduler >> echo "bfq" > /sys/block/sdb/queue/scheduler >> > > Great, I got these informations before starting a kernel-build. > > So, I have now... > > $ ./scripts/diffconfig /boot/config-4.11.0-1-iniza-amd64 .config > -BLK_DEV_HD n > SCSI_MQ_DEFAULT n -> y > +BFQ_GROUP_IOSCHED y > +BLK_DEV_THROTTLING_LOW n > +IOSCHED_BFQ y > +MQ_IOSCHED_KYBER y > > Thanks, Markus. > This worked... # cat /sys/block/sda/queue/scheduler [mq-deadline] kyber bfq none # echo "bfq" > /sys/block/sda/queue/scheduler # cat /sys/block/sda/queue/scheduler mq-deadline kyber [bfq] none - sed@ -
On Tue, May 2, 2017 at 10:00 AM, Markus Trippelsdorf <markus@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 :-). - 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 [2] http://algo.ing.unimo.it/people/paolo/disk_sched/patches/4.11.0-v8r11/0002-block-introduce-the-BFQ-v7r11-I-O-sched-for-4.11.0.patch [3] http://algo.ing.unimo.it/people/paolo/disk_sched/patches/4.11.0-v8r11/0003-block-bfq-add-Early-Queue-Merge-EQM-to-BFQ-v7r11-for.patch [4] http://algo.ing.unimo.it/people/paolo/disk_sched/patches/4.11.0-v8r11/0004-blk-bfq-turn-BFQ-v7r11-for-4.11.0-into-BFQ-v8r11-for.patch
On 2017.05.02 at 14:07 +0200, Sedat Dilek wrote: > On Tue, May 2, 2017 at 10:00 AM, Markus Trippelsdorf > <markus@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.
On Tue, May 2, 2017 at 2:16 PM, Markus Trippelsdorf <markus@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 >> <markus@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. 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 Thanks. - sed@ -
On 2017.05.03 at 10:00 +0200, Sedat Dilek wrote: > On Tue, May 2, 2017 at 2:16 PM, Markus Trippelsdorf > <markus@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 > >> <markus@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. > > So if MQ is the way why isn't the Kconfig called CONFIG_MQ_IOSCHED_BFQ > according to CONFIG_MQ_IOSCHED_DEADLINE? Good point. The current naming is confusing. Also: # cat /sys/block/sda/queue/scheduler mq-deadline [kyber] bfq none These should all be prefixed with mq-.
> Il giorno 03 mag 2017, alle ore 10:00, Sedat Dilek <sedat.dilek@gmail.com> ha scritto: > > On Tue, May 2, 2017 at 2:16 PM, Markus Trippelsdorf > <markus@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 >>> <markus@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 > 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. Thanks, Paolo > Thanks. > > - sed@ -
> Il giorno 03 mag 2017, alle ore 11:16, Markus Trippelsdorf <markus@trippelsdorf.de> ha scritto: > > On 2017.05.03 at 10:00 +0200, Sedat Dilek wrote: >> On Tue, May 2, 2017 at 2:16 PM, Markus Trippelsdorf >> <markus@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 >>>> <markus@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. >> >> So if MQ is the way why isn't the Kconfig called CONFIG_MQ_IOSCHED_BFQ >> according to CONFIG_MQ_IOSCHED_DEADLINE? > > Good point. The current naming is confusing. > > Also: > # cat /sys/block/sda/queue/scheduler > mq-deadline [kyber] bfq none > > These should all be prefixed with mq-. > The logic here, as proposed by Jens, is not to add the mq tag when there is no risk of ambiguity (such as between deadline and mq-deadline). I'm open to any sensible choice. Thanks, Paolo > -- > Markus
> Il giorno 13 mag 2017, alle ore 09:50, Sedat Dilek <sedat.dilek@gmail.com> ha scritto: > > On Wed, May 3, 2017 at 11:21 AM, Paolo Valente <paolo.valente@linaro.org> wrote: >> >>> Il giorno 03 mag 2017, alle ore 10:00, Sedat Dilek <sedat.dilek@gmail.com> ha scritto: >>> >>> On Tue, May 2, 2017 at 2:16 PM, Markus Trippelsdorf >>> <markus@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 >>>>> <markus@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). > 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>
On Tue, May 16, 2017 at 10:45 AM, Paolo Valente <paolo.valente@linaro.org> wrote: > >> Il giorno 13 mag 2017, alle ore 09:50, Sedat Dilek <sedat.dilek@gmail.com> ha scritto: >> >> On Wed, May 3, 2017 at 11:21 AM, Paolo Valente <paolo.valente@linaro.org> wrote: >>> >>>> Il giorno 03 mag 2017, alle ore 10:00, Sedat Dilek <sedat.dilek@gmail.com> ha scritto: >>>> >>>> On Tue, May 2, 2017 at 2:16 PM, Markus Trippelsdorf >>>> <markus@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 >>>>>> <markus@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. 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
> Il giorno 16 mag 2017, alle ore 15:22, Sedat Dilek <sedat.dilek@gmail.com> ha scritto: > > On Tue, May 16, 2017 at 10:45 AM, Paolo Valente > <paolo.valente@linaro.org> wrote: >> >>> Il giorno 13 mag 2017, alle ore 09:50, Sedat Dilek <sedat.dilek@gmail.com> ha scritto: >>> >>> On Wed, May 3, 2017 at 11:21 AM, Paolo Valente <paolo.valente@linaro.org> wrote: >>>> >>>>> Il giorno 03 mag 2017, alle ore 10:00, Sedat Dilek <sedat.dilek@gmail.com> ha scritto: >>>>> >>>>> On Tue, May 2, 2017 at 2:16 PM, Markus Trippelsdorf >>>>> <markus@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 >>>>>>> <markus@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
[...] >>>> 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. > I recall, Markus pointed me to that difference between the BFQ implementations. For testing purposes: You want people to test BFQ in Linux v4.12? - Sedat - > 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 >
> Il giorno 16 mag 2017, alle ore 15:38, Sedat Dilek <sedat.dilek@gmail.com> ha scritto: > > [...] > >>>>> 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. >> > > I recall, Markus pointed me to that difference between the BFQ implementations. > For testing purposes: You want people to test BFQ in Linux v4.12? > That would be awesome. For the moment, I would be very happy even if it just didn't crash! Thanks, Paolo > - Sedat - > >> 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 >>
From da3379424fc0237d5de25e946ed5482a625aaac2 Mon Sep 17 00:00:00 2001 From: Sedat Dilek <sedat.dilek@gmail.com> Date: Tue, 2 May 2017 09:33:27 +0200 Subject: [PATCH] block: bfq: Introduce DEFAULT_BFQ --- block/Kconfig.iosched | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/block/Kconfig.iosched b/block/Kconfig.iosched index 8ea2c8d77100..f37455dcf381 100644 --- a/block/Kconfig.iosched +++ b/block/Kconfig.iosched @@ -73,6 +73,9 @@ choice config DEFAULT_CFQ bool "CFQ" if IOSCHED_CFQ=y + config DEFAULT_BFQ + bool "BFQ" if IOSCHED_BFQ=y + config DEFAULT_NOOP bool "No-op" @@ -82,6 +85,7 @@ config DEFAULT_IOSCHED string default "deadline" if DEFAULT_DEADLINE default "cfq" if DEFAULT_CFQ + default "bfq" if DEFAULT_BFQ default "noop" if DEFAULT_NOOP config MQ_IOSCHED_DEADLINE -- 2.11.0