On Tue, 18 Jul 2017 23:58:03 +0800
Jonathan Cameron wrote:
> On Fri, 14 Jul 2017 14:45:39 +0200
> "h...@lst.de" wrote:
>
> > On Fri, Jul 14, 2017 at 05:56:41PM +0800, Jonathan Cameron wrote:
> > > Just wondering if you had any thoughts on how we can
On Fri, 14 Jul 2017 14:45:39 +0200
"h...@lst.de" wrote:
> On Fri, Jul 14, 2017 at 05:56:41PM +0800, Jonathan Cameron wrote:
> > Just wondering if you had any thoughts on how we can proceed with tracking
> > down this regression?
> >
> > I'm not familiar enough with the multiqueue
On Fri, Jul 14, 2017 at 05:56:41PM +0800, Jonathan Cameron wrote:
> Just wondering if you had any thoughts on how we can proceed with tracking
> down this regression?
>
> I'm not familiar enough with the multiqueue code to really know where
> to start.
>
> If there are any other tests that would
On Wed, 12 Jul 2017 23:54:01 +0800
Jonathan Cameron wrote:
> On Wed, 12 Jul 2017 14:18:14 +
> Bart Van Assche wrote:
>
> > On Wed, 2017-07-12 at 09:26 +0100, John Garry wrote:
> > > > > What block driver controls the block device for
On Wed, 12 Jul 2017 14:18:14 +
Bart Van Assche wrote:
> On Wed, 2017-07-12 at 09:26 +0100, John Garry wrote:
> > > > What block driver controls the block device for which the performance
> > > > regression
> > > > has been observed? How many hardware queues were
On Wed, 2017-07-12 at 09:26 +0100, John Garry wrote:
> > > What block driver controls the block device for which the performance
> > > regression
> > > has been observed? How many hardware queues were created by that block
> > > driver
> > > (see also /sys/block/*/mq/...)?
>
> Just confirming
What block driver controls the block device for which the performance
regression
has been observed? How many hardware queues were created by that block
driver
(see also /sys/block/*/mq/...)?
Just confirming that we have only 1 queue:
/sys/block/sdc/mq/0 as example
Hi Bart,
Here's the shost
On 11/07/2017 16:46, Bart Van Assche wrote:
On Tue, 2017-07-11 at 15:14 +0100, John Garry wrote:
On 11/07/2017 14:32, Bart Van Assche wrote:
On Tue, 2017-07-11 at 11:22 +0100, John Garry wrote:
On 10/07/2017 16:50, Bart Van Assche wrote:
Since a fix for the performance regression triggered
On Tue, 2017-07-11 at 15:14 +0100, John Garry wrote:
> On 11/07/2017 14:32, Bart Van Assche wrote:
> > On Tue, 2017-07-11 at 11:22 +0100, John Garry wrote:
> > > On 10/07/2017 16:50, Bart Van Assche wrote:
> > > > Since a fix for the performance regression triggered by this patch will
> > > > be
On 11/07/2017 14:32, Bart Van Assche wrote:
On Tue, 2017-07-11 at 11:22 +0100, John Garry wrote:
On 10/07/2017 16:50, Bart Van Assche wrote:
Since a fix for the performance regression triggered by this patch will be
upstream
soon (see also
On Tue, 2017-07-11 at 11:22 +0100, John Garry wrote:
> On 10/07/2017 16:50, Bart Van Assche wrote:
> > Since a fix for the performance regression triggered by this patch will be
> > upstream
> > soon (see also
> >
On 10/07/2017 16:50, Bart Van Assche wrote:
On Fri, 2017-06-16 at 10:27 +0200, Christoph Hellwig wrote:
Remove the SCSI_MQ_DEFAULT config option and default to the blk-mq I/O
path now that we had plenty of testing, and have I/O schedulers for
blk-mq. The module option to disable the blk-mq
On Fri, 2017-06-16 at 10:27 +0200, Christoph Hellwig wrote:
> Remove the SCSI_MQ_DEFAULT config option and default to the blk-mq I/O
> path now that we had plenty of testing, and have I/O schedulers for
> blk-mq. The module option to disable the blk-mq path is kept around
> for now.
>
>
On Mon, 2017-06-26 at 20:55 +0200, Martin Wilck wrote:
> I personally find it odd that the compile-time choice goes away while
> the run-time choice remains available. I understand what Christoph is
> trying to achieve, but if it was up to me, I'd prefer to change the
> default and mark the "n"
Hi Bart,
On Mon, 2017-06-26 at 15:31 +, Bart Van Assche wrote:
> On Mon, 2017-06-26 at 12:13 +, Bart Van Assche wrote:
> > On Thu, 2017-06-22 at 17:05 +0200, Martin Wilck wrote:
> > > On Fri, 2017-06-16 at 10:27 +0200, Christoph Hellwig wrote:
> > > > Remove the SCSI_MQ_DEFAULT config
On Mon, 2017-06-26 at 12:13 +, Bart Van Assche wrote:
> On Thu, 2017-06-22 at 17:05 +0200, Martin Wilck wrote:
> > On Fri, 2017-06-16 at 10:27 +0200, Christoph Hellwig wrote:
> > > Remove the SCSI_MQ_DEFAULT config option and default to the blk-mq
> > > I/O
> > > path now that we had plenty of
On Thu, 2017-06-22 at 17:05 +0200, Martin Wilck wrote:
> On Fri, 2017-06-16 at 10:27 +0200, Christoph Hellwig wrote:
> > Remove the SCSI_MQ_DEFAULT config option and default to the blk-mq
> > I/O
> > path now that we had plenty of testing, and have I/O schedulers for
> > blk-mq. The module option
On Thu, Jun 22, 2017 at 05:05:33PM +0200, Martin Wilck wrote:
> Hello Christoph,
>
> On Fri, 2017-06-16 at 10:27 +0200, Christoph Hellwig wrote:
> > Remove the SCSI_MQ_DEFAULT config option and default to the blk-mq
> > I/O
> > path now that we had plenty of testing, and have I/O schedulers for
>
Hello Christoph,
On Fri, 2017-06-16 at 10:27 +0200, Christoph Hellwig wrote:
> Remove the SCSI_MQ_DEFAULT config option and default to the blk-mq
> I/O
> path now that we had plenty of testing, and have I/O schedulers for
> blk-mq. The module option to disable the blk-mq path is kept around
>
19 matches
Mail list logo