On Thu, Mar 21, 2013 at 09:04:20PM +0800, Zhi Yong Wu wrote:
> On Thu, 2013-03-21 at 10:17 +0100, Stefan Hajnoczi wrote:
> > On Thu, Mar 21, 2013 at 09:18:27AM +0800, Zhi Yong Wu wrote:
> > > On Wed, 2013-03-20 at 16:12 +0100, Stefan Hajnoczi wrote:
> > > > On Wed, Mar 20, 2013 at 03:56:33PM +0100,
The +1 was here to account the current request as already done in this slice.
Statistically there is 50% chance that it will be wrong.
I toyed adding + 0.5 add wait_time doesn't drift anymore while iops don't
oscillate.
diff --git a/block.c b/block.c
index 0a062c9..455d8b0 100644
--- a/block.c
++
On Thu, 2013-03-21 at 10:17 +0100, Stefan Hajnoczi wrote:
> On Thu, Mar 21, 2013 at 09:18:27AM +0800, Zhi Yong Wu wrote:
> > On Wed, 2013-03-20 at 16:12 +0100, Stefan Hajnoczi wrote:
> > > On Wed, Mar 20, 2013 at 03:56:33PM +0100, Benoît Canet wrote:
> > > > > But I don't understand why bs->slice_t
On Wed, Mar 20, 2013 at 04:27:14PM +0100, Benoît Canet wrote:
> > Now there is no oscillation and the wait_times do not grow or shrink
> > under constant load from dd(1).
> >
> > Can you try this patch by itself to see if it fixes the oscillation?
>
> On my test setup it fixes the oscillation and
On Thu, Mar 21, 2013 at 09:18:27AM +0800, Zhi Yong Wu wrote:
> On Wed, 2013-03-20 at 16:12 +0100, Stefan Hajnoczi wrote:
> > On Wed, Mar 20, 2013 at 03:56:33PM +0100, Benoît Canet wrote:
> > > > But I don't understand why bs->slice_time is modified instead of keeping
> > > > it constant at 100 ms:
On Wed, 2013-03-20 at 16:12 +0100, Stefan Hajnoczi wrote:
> On Wed, Mar 20, 2013 at 03:56:33PM +0100, Benoît Canet wrote:
> > > But I don't understand why bs->slice_time is modified instead of keeping
> > > it constant at 100 ms:
> > >
> > > bs->slice_time = wait_time * BLOCK_IO_SLICE_TIME * 10
> Now there is no oscillation and the wait_times do not grow or shrink
> under constant load from dd(1).
>
> Can you try this patch by itself to see if it fixes the oscillation?
On my test setup it fixes the oscillation and lead to an average 149.88 iops.
However another pattern appear.
iostat -d
On Wed, Mar 20, 2013 at 03:56:33PM +0100, Benoît Canet wrote:
> > But I don't understand why bs->slice_time is modified instead of keeping
> > it constant at 100 ms:
> >
> > bs->slice_time = wait_time * BLOCK_IO_SLICE_TIME * 10;
> > bs->slice_end += bs->slice_time - 3 * BLOCK_IO_SLICE_TIME;
> But I don't understand why bs->slice_time is modified instead of keeping
> it constant at 100 ms:
>
> bs->slice_time = wait_time * BLOCK_IO_SLICE_TIME * 10;
> bs->slice_end += bs->slice_time - 3 * BLOCK_IO_SLICE_TIME;
> if (wait) {
> *wait = wait_time * BLOCK_IO_SLICE_TIME * 1
On Wed, Mar 20, 2013 at 02:29:24PM +0100, Stefan Hajnoczi wrote:
> On Wed, Mar 20, 2013 at 10:12:14AM +0100, Benoît Canet wrote:
> > This patch fix an I/O throttling behavior triggered by limiting at 150 iops
> > and running a load of 50 threads doing random pwrites on a raw virtio
> > device.
> >
On Wed, Mar 20, 2013 at 10:12:14AM +0100, Benoît Canet wrote:
> This patch fix an I/O throttling behavior triggered by limiting at 150 iops
> and running a load of 50 threads doing random pwrites on a raw virtio device.
>
> After a few moments the iops count start to oscillate steadily between 0 a
Reviewed-by: Zhi Yong Wu
On Wed, 2013-03-20 at 10:12 +0100, Benoît Canet wrote:
> This patch fix an I/O throttling behavior triggered by limiting at 150 iops
> and running a load of 50 threads doing random pwrites on a raw virtio device.
>
> After a few moments the iops count start to oscillate
This patch fix an I/O throttling behavior triggered by limiting at 150 iops
and running a load of 50 threads doing random pwrites on a raw virtio device.
After a few moments the iops count start to oscillate steadily between 0 and a
value upper than the limit.
As the load keep running the period
13 matches
Mail list logo
