On Wed, Nov 09, 2016 at 09:07:08AM -0700, Jens Axboe wrote:
> On 11/09/2016 01:40 AM, Jan Kara wrote:
> >Also I'm not sure why such logic for devices with writeback cache is
> >needed. Sure the disk is fast to accept writes but if that causes long
> >read latencies, we should scale down the
On 11/09/2016 09:07 AM, Jens Axboe wrote:
On 11/09/2016 01:40 AM, Jan Kara wrote:
So for devices with write cache, you will completely drain the device
before waking anybody waiting to issue new requests. Isn't it too
strict?
In particular may_queue() will allow new writers to issue new writes
On 11/09/2016 01:40 AM, Jan Kara wrote:
So for devices with write cache, you will completely drain the device
before waking anybody waiting to issue new requests. Isn't it too strict?
In particular may_queue() will allow new writers to issue new writes once
we drop below the limit so it can
On Tue, Nov 08 2016, Jan Kara wrote:
> On Tue 01-11-16 15:08:50, Jens Axboe wrote:
> > We can hook this up to the block layer, to help throttle buffered
> > writes.
> >
> > wbt registers a few trace points that can be used to track what is
> > happening in the system:
> >
> > wbt_lat: 259:0:
On Tue 01-11-16 15:08:50, Jens Axboe wrote:
> We can hook this up to the block layer, to help throttle buffered
> writes.
>
> wbt registers a few trace points that can be used to track what is
> happening in the system:
>
> wbt_lat: 259:0: latency 2446318
> wbt_stat: 259:0: rmean=2446318,
We can hook this up to the block layer, to help throttle buffered
writes.
wbt registers a few trace points that can be used to track what is
happening in the system:
wbt_lat: 259:0: latency 2446318
wbt_stat: 259:0: rmean=2446318, rmin=2446318, rmax=2446318, rsamples=1,
We can hook this up to the block layer, to help throttle buffered
writes.
wbt registers a few trace points that can be used to track what is
happening in the system:
wbt_lat: 259:0: latency 2446318
wbt_stat: 259:0: rmean=2446318, rmin=2446318, rmax=2446318, rsamples=1,
