On Wed, Nov 25, 2015 at 12:47:21PM -0700, Jens Axboe wrote:
> On 11/19/2015 05:02 AM, Andreas Herrmann wrote:
--8<--
> >The latter helped to improve performance for sequential reads and
> >writes. But it's not on a par with CFQ. Increasing the time slice is
> >suboptimal (as shown with the 2ms
On Tue, Nov 24, 2015 at 09:19:32AM +0100, Christoph Hellwig wrote:
> Hi Andreas,
Hi Christoph,
> I don't understand the time slicing algorithm to well, but from the
> blk-mq integration perspective this looks nice, and anything that
> helps improving blk-mq for spinning rust is useful.
I'll put
On Wed, Nov 25, 2015 at 12:47:21PM -0700, Jens Axboe wrote:
> On 11/19/2015 05:02 AM, Andreas Herrmann wrote:
--8<--
> >The latter helped to improve performance for sequential reads and
> >writes. But it's not on a par with CFQ. Increasing the time slice is
> >suboptimal (as shown with the 2ms
On Tue, Nov 24, 2015 at 09:19:32AM +0100, Christoph Hellwig wrote:
> Hi Andreas,
Hi Christoph,
> I don't understand the time slicing algorithm to well, but from the
> blk-mq integration perspective this looks nice, and anything that
> helps improving blk-mq for spinning rust is useful.
I'll put
On 11/19/2015 05:02 AM, Andreas Herrmann wrote:
Hi,
I've looked into blk-mq and possible support for I/O scheduling.
The reason for this is to minimize performance degradation with
rotational devices when scsi_mod.use_blk_mq=1 is switched on.
I think that the degradation is well reflected
On 11/19/2015 05:02 AM, Andreas Herrmann wrote:
Hi,
I've looked into blk-mq and possible support for I/O scheduling.
The reason for this is to minimize performance degradation with
rotational devices when scsi_mod.use_blk_mq=1 is switched on.
I think that the degradation is well reflected
Hi Andreas,
I don't understand the time slicing algorithm to well, but from the
blk-mq integration perspective this looks nice, and anything that
helps improving blk-mq for spinning rust is useful.
As a nitpick some of the larger "if (use_time_slice)" blocks should
be moved into separate helper
Hi Andreas,
I don't understand the time slicing algorithm to well, but from the
blk-mq integration perspective this looks nice, and anything that
helps improving blk-mq for spinning rust is useful.
As a nitpick some of the larger "if (use_time_slice)" blocks should
be moved into separate helper
Hi,
I've looked into blk-mq and possible support for I/O scheduling.
The reason for this is to minimize performance degradation with
rotational devices when scsi_mod.use_blk_mq=1 is switched on.
I think that the degradation is well reflected with fio measurements.
With an increasing number of
Hi,
I've looked into blk-mq and possible support for I/O scheduling.
The reason for this is to minimize performance degradation with
rotational devices when scsi_mod.use_blk_mq=1 is switched on.
I think that the degradation is well reflected with fio measurements.
With an increasing number of
10 matches
Mail list logo