Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1510515 > unrolled thread

Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler Ulf Hansson <ulf.hansson@linaro.org> - 2016-10-27 19:40 +0200
    Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra  scheduler Jens Axboe <axboe@kernel.dk> - 2016-10-27 19:50 +0200
      Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler Ulf Hansson <ulf.hansson@linaro.org> - 2016-10-27 20:20 +0200
        Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra  scheduler Jens Axboe <axboe@kernel.dk> - 2016-10-27 20:30 +0200
          Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler Ulf Hansson <ulf.hansson@linaro.org> - 2016-10-27 21:40 +0200
            Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra  scheduler Jens Axboe <axboe@kernel.dk> - 2016-10-27 23:10 +0200
              Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler Linus Walleij <linus.walleij@linaro.org> - 2016-10-28 00:30 +0200
                Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler Linus Walleij <linus.walleij@linaro.org> - 2016-10-28 11:40 +0200
                  Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra  scheduler Jens Axboe <axboe@kernel.dk> - 2016-10-28 16:30 +0200
                    Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler Linus Walleij <linus.walleij@linaro.org> - 2016-10-28 22:40 +0200
                  Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra  scheduler Christoph Hellwig <hch@infradead.org> - 2016-10-28 17:30 +0200
                    Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler Linus Walleij <linus.walleij@linaro.org> - 2016-10-28 23:10 +0200
                  Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra  scheduler Jens Axboe <axboe@kernel.dk> - 2016-10-28 17:40 +0200
                    Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra  scheduler Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> - 2016-10-28 18:00 +0200
                    Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler Arnd Bergmann <arnd@arndb.de> - 2016-10-28 18:10 +0200
                      Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra  scheduler Mark Brown <broonie@kernel.org> - 2016-10-28 19:20 +0200
                Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra  scheduler Jens Axboe <axboe@kernel.dk> - 2016-10-28 16:10 +0200
              Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler Ulf Hansson <ulf.hansson@linaro.org> - 2016-10-28 08:40 +0200
                Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra  scheduler Jens Axboe <axboe@kernel.dk> - 2016-10-28 16:20 +0200
                  Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra  scheduler Mark Brown <broonie@kernel.org> - 2016-10-28 19:20 +0200
          Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra  scheduler Christoph Hellwig <hch@infradead.org> - 2016-10-27 21:50 +0200
            Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra  scheduler Mark Brown <broonie@kernel.org> - 2016-10-28 00:10 +0200
          Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra  scheduler Mark Brown <broonie@kernel.org> - 2016-10-27 21:50 +0200
        Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler Arnd Bergmann <arnd@arndb.de> - 2016-10-28 14:10 +0200
          Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler Richard Weinberger <richard.weinberger@gmail.com> - 2016-10-28 14:20 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1510609 — Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

On Thu, Oct 27, 2016 at 08:41:27PM +0100, Mark Brown wrote:
> Plus the benchmarking to verify that it works well of course, especially
> initially where it'll also be a new queue infrastructure as well as the
> blk-mq conversion itself.  It does feel like something that's going to
> take at least a couple of kernel releases to get through.

Or to put it the other way around:  it could have been long done
if people had started it the first it was suggestead.  Instead you guys
keep arguing and nothing gets done.  Get started now, waiting won't
make anything go faster.

> I think there's also value in having improvements there for people who
> benefit from them while queue infrastructure for blk-mq is being worked
> on.  

Well, apply it to you vendor tree then and maintain it yourself if you
disagree with our direction.

[toc] | [prev] | [next] | [standalone]

#1510702 — Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

[Multipart message — attachments visible in raw view] — view raw

On Thu, Oct 27, 2016 at 12:45:48PM -0700, Christoph Hellwig wrote:
> On Thu, Oct 27, 2016 at 08:41:27PM +0100, Mark Brown wrote:

> > Plus the benchmarking to verify that it works well of course, especially
> > initially where it'll also be a new queue infrastructure as well as the
> > blk-mq conversion itself.  It does feel like something that's going to
> > take at least a couple of kernel releases to get through.

> Or to put it the other way around:  it could have been long done
> if people had started it the first it was suggestead.  Instead you guys
> keep arguing and nothing gets done.  Get started now, waiting won't
> make anything go faster.

There are things going on already like the effort to convert MMC to
blk-mq and there have been some initial emails with Omar about how best
to collaborate on his existing work (which was pointed out as the way
forwards) so that things are useful and we avoid duplication of effort.
In any case the situation is what it is, we can't change the past.

> > I think there's also value in having improvements there for people who
> > benefit from them while queue infrastructure for blk-mq is being worked
> > on.  

> Well, apply it to you vendor tree then and maintain it yourself if you
> disagree with our direction.

I don't think there's any substantial disagreement about where we want
to end up, it's a much more tactical discussion about what we do while
we're on the way there.  Just saying put the changes in your vendor tree
isn't ideal, it's not like there's some singular vendor tree out there
that everyone uses and doing things in vendor trees is what we mostly
encourage people to avoid doing.

If it were something that was actively disruptive for other users or it
made the blk-mq code harder to work with then it'd be clear that having
it upstream would cause problems but that doesn't seem to be the case
here.  Similarly if blk-mq were already at the point where it could
replace blk then it'd be clear that drivers should just be being
converted.  Instead we're in the middle somewhere, it wouldn't be
entirely free to put something in but on the other hand helps solve
people's problems and where it's causing costs those costs are also
providing a hook that helps pull people into working with the community
more.

[toc] | [prev] | [next] | [standalone]

#1510614 — Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra scheduler

[Multipart message — attachments visible in raw view] — view raw

On Thu, Oct 27, 2016 at 12:21:06PM -0600, Jens Axboe wrote:
> On 10/27/2016 12:13 PM, Ulf Hansson wrote:

> > I can imagine, that it's not always a straight forward "convert to blk
> > mq" patch for every block device driver.

> Well, I've actually done a few conversions, and it's not difficult at
> all. The grunt of the work is usually around converting to using some of
> the blk-mq features for parts of the driver that it had implemented
> privately, like timeout handling, etc.

Plus the benchmarking to verify that it works well of course, especially
initially where it'll also be a new queue infrastructure as well as the
blk-mq conversion itself.  It does feel like something that's going to
take at least a couple of kernel releases to get through.

> > > > 3)
> > > > While we work on scheduling in blkmq (at least for single queue
> > > > devices), it's of course important that we set high goals. Having BFQ
> > > > (and the other schedulers) in the legacy blk, provides a good
> > > > reference for what we could aim for.

> > > Sure, but you don't need BFQ to be included in the kernel for that.

> > Perhaps not.

> > But does that mean, you expect Paolo to maintain an up to date BFQ
> > tree for you?

> I don't expect anything. If Paolo or others want to compare with BFQ on
> the legacy IO path, then they can do that however way they want. If you
> (and others) want to have that reference point, it's up to you how to
> accomplish that.

I think there's also value in having improvements there for people who
benefit from them while queue infrastructure for blk-mq is being worked
on.  

[toc] | [prev] | [next] | [standalone]

#1511084

On Thursday, October 27, 2016 8:13:08 PM CEST Ulf Hansson wrote:
> On 27 October 2016 at 19:43, Jens Axboe <axboe@kernel.dk> wrote:
> > On 10/27/2016 11:32 AM, Ulf Hansson wrote:
> >>
> >> [...]
> >>
> >>>
> >>> I'm hesistant to add a new scheduler because it's very easy to add, very
> >>> difficult to get rid of. If we do add BFQ as a legacy scheduler now,
> >>> it'll take us years and years to get rid of it again. We should be
> >>> moving towards LESS moving parts in the legacy path, not more.
> >>
> >>
> >> Jens, I think you are wrong here and let me try to elaborate on why.
> >>
> >> 1)
> >> We already have legacy schedulers like CFQ, DEADLINE, etc - and most
> >> block device drivers are still using the legacy blk interface.
> >
> >
> > I don't think that's an accurate statement. In terms of coverage, most
> > drivers do support blk-mq. Anything SCSI, nvme, virtio-blk, SATA runs on
> > (or can run on) top of blk-mq.
> 
> Well, I just used "git grep" and found that many drivers didn't use
> blkmq. Apologize if I gave the wrong impressions.

To clarify, this seems to be a complete list:

$ git grep -wl '\(__\|\)blk_\(fetch\|end\|start\)_request' | xargs grep -L blk_mq
Documentation/scsi/scsi_eh.txt
arch/um/drivers/ubd_kern.c
block/blk-tag.c
block/bsg-lib.c
drivers/block/DAC960.c
drivers/block/amiflop.c
drivers/block/aoe/aoeblk.c
drivers/block/aoe/aoecmd.c
drivers/block/aoe/aoedev.c
drivers/block/ataflop.c
drivers/block/cciss.c
drivers/block/floppy.c
drivers/block/hd.c
drivers/block/mg_disk.c
drivers/block/osdblk.c
drivers/block/paride/pcd.c
drivers/block/paride/pd.c
drivers/block/paride/pf.c
drivers/block/ps3disk.c
drivers/block/skd_main.c
drivers/block/sunvdc.c
drivers/block/swim.c
drivers/block/swim3.c
drivers/block/sx8.c
drivers/block/xsysace.c
drivers/block/z2ram.c
drivers/cdrom/gdrom.c
drivers/ide/ide-atapi.c
drivers/ide/ide-io.c
drivers/ide/ide-pm.c
drivers/memstick/core/ms_block.c
drivers/memstick/core/mspro_block.c
drivers/mmc/card/block.c
drivers/mmc/card/queue.c
drivers/mtd/mtd_blkdevs.c
drivers/s390/block/dasd.c
drivers/s390/block/scm_blk.c
drivers/sbus/char/jsflash.c
drivers/scsi/osd/osd_initiator.c
drivers/scsi/scsi_transport_fc.c
drivers/scsi/scsi_transport_sas.c
samples/bpf/tracex3_kern.c

From what I can tell, most of these are hopelessly obsolete, but
there are some notable exceptions: aoe, osdblk, skd, sunvdc, mtdblk,
mmc, dasd and scm. I've never used any of the first four, but the
last four of the list are certainly important (for very different
reasons).

	Arnd

[toc] | [prev] | [next] | [standalone]

#1511091

On Fri, Oct 28, 2016 at 2:07 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > I don't think that's an accurate statement. In terms of coverage, most
>> > drivers do support blk-mq. Anything SCSI, nvme, virtio-blk, SATA runs on
>> > (or can run on) top of blk-mq.
>>
>> Well, I just used "git grep" and found that many drivers didn't use
>> blkmq. Apologize if I gave the wrong impressions.
>
> To clarify, this seems to be a complete list:
>
> $ git grep -wl '\(__\|\)blk_\(fetch\|end\|start\)_request' | xargs grep -L blk_mq
> Documentation/scsi/scsi_eh.txt
> arch/um/drivers/ubd_kern.c

AFAICT Daniel looked at the UML block driver and did an initial
conversion some time ago.
Daniel?
Anton is also working on a patch series to speed up the driver.
Maybe it is time to bite the bullet and do the conversion.

-- 
Thanks,
//richard

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web