We can hook this up to the block layer, to help throttle buffered
writes. Or NFS can tap into it, to accomplish the same.
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,
We can hook this up to the block layer, to help throttle buffered
writes. Or NFS can tap into it, to accomplish the same.
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,
On 09/01/2016 12:05 PM, Omar Sandoval wrote:
diff --git a/lib/Kconfig b/lib/Kconfig
index d79909dc01ec..5a65a1f91889 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -550,4 +550,8 @@ config STACKDEPOT
bool
select STACKTRACE
+config WBT
+ bool
+ select SCALE_BITMAP
On 09/01/2016 12:05 PM, Omar Sandoval wrote:
diff --git a/lib/Kconfig b/lib/Kconfig
index d79909dc01ec..5a65a1f91889 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -550,4 +550,8 @@ config STACKDEPOT
bool
select STACKTRACE
+config WBT
+ bool
+ select SCALE_BITMAP
On Wed, Aug 31, 2016 at 11:05:50AM -0600, Jens Axboe wrote:
> We can hook this up to the block layer, to help throttle buffered
> writes. Or NFS can tap into it, to accomplish the same.
>
> wbt registers a few trace points that can be used to track what is
> happening in the system:
>
> wbt_lat:
On Wed, Aug 31, 2016 at 11:05:50AM -0600, Jens Axboe wrote:
> We can hook this up to the block layer, to help throttle buffered
> writes. Or NFS can tap into it, to accomplish the same.
>
> wbt registers a few trace points that can be used to track what is
> happening in the system:
>
> wbt_lat:
We can hook this up to the block layer, to help throttle buffered
writes. Or NFS can tap into it, to accomplish the same.
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,
We can hook this up to the block layer, to help throttle buffered
writes. Or NFS can tap into it, to accomplish the same.
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,
On 05/03/2016 12:14 PM, Jens Axboe wrote:
On 05/03/2016 10:59 AM, Jens Axboe wrote:
On 05/03/2016 09:48 AM, Jan Kara wrote:
On Tue 03-05-16 17:40:32, Jan Kara wrote:
On Tue 03-05-16 11:34:10, Jan Kara wrote:
Yeah, once I'll hunt down that regression with old disk, I can have
a look
into how
On 05/03/2016 12:14 PM, Jens Axboe wrote:
On 05/03/2016 10:59 AM, Jens Axboe wrote:
On 05/03/2016 09:48 AM, Jan Kara wrote:
On Tue 03-05-16 17:40:32, Jan Kara wrote:
On Tue 03-05-16 11:34:10, Jan Kara wrote:
Yeah, once I'll hunt down that regression with old disk, I can have
a look
into how
On 05/03/2016 10:59 AM, Jens Axboe wrote:
On 05/03/2016 09:48 AM, Jan Kara wrote:
On Tue 03-05-16 17:40:32, Jan Kara wrote:
On Tue 03-05-16 11:34:10, Jan Kara wrote:
Yeah, once I'll hunt down that regression with old disk, I can have
a look
into how writeback throttling plays together with
On 05/03/2016 10:59 AM, Jens Axboe wrote:
On 05/03/2016 09:48 AM, Jan Kara wrote:
On Tue 03-05-16 17:40:32, Jan Kara wrote:
On Tue 03-05-16 11:34:10, Jan Kara wrote:
Yeah, once I'll hunt down that regression with old disk, I can have
a look
into how writeback throttling plays together with
On 05/03/2016 09:48 AM, Jan Kara wrote:
On Tue 03-05-16 17:40:32, Jan Kara wrote:
On Tue 03-05-16 11:34:10, Jan Kara wrote:
Yeah, once I'll hunt down that regression with old disk, I can have a look
into how writeback throttling plays together with blkio-controller.
So I've tried the
On 05/03/2016 09:48 AM, Jan Kara wrote:
On Tue 03-05-16 17:40:32, Jan Kara wrote:
On Tue 03-05-16 11:34:10, Jan Kara wrote:
Yeah, once I'll hunt down that regression with old disk, I can have a look
into how writeback throttling plays together with blkio-controller.
So I've tried the
On Tue 03-05-16 17:40:32, Jan Kara wrote:
> On Tue 03-05-16 11:34:10, Jan Kara wrote:
> > Yeah, once I'll hunt down that regression with old disk, I can have a look
> > into how writeback throttling plays together with blkio-controller.
>
> So I've tried the following script (note that you need
On Tue 03-05-16 17:40:32, Jan Kara wrote:
> On Tue 03-05-16 11:34:10, Jan Kara wrote:
> > Yeah, once I'll hunt down that regression with old disk, I can have a look
> > into how writeback throttling plays together with blkio-controller.
>
> So I've tried the following script (note that you need
On Tue 03-05-16 11:34:10, Jan Kara wrote:
> Yeah, once I'll hunt down that regression with old disk, I can have a look
> into how writeback throttling plays together with blkio-controller.
So I've tried the following script (note that you need cgroup v2 for
writeback IO to be throttled):
---
On Tue 03-05-16 11:34:10, Jan Kara wrote:
> Yeah, once I'll hunt down that regression with old disk, I can have a look
> into how writeback throttling plays together with blkio-controller.
So I've tried the following script (note that you need cgroup v2 for
writeback IO to be throttled):
---
On 05/03/2016 09:22 AM, Jan Kara wrote:
On Tue 03-05-16 08:23:27, Jens Axboe wrote:
On 05/03/2016 03:34 AM, Jan Kara wrote:
On Thu 28-04-16 12:53:50, Jens Axboe wrote:
2) As far as I can see in patch 8/8, you have plugged the throttling above
the IO scheduler. When there are e.g. multiple
On 05/03/2016 09:22 AM, Jan Kara wrote:
On Tue 03-05-16 08:23:27, Jens Axboe wrote:
On 05/03/2016 03:34 AM, Jan Kara wrote:
On Thu 28-04-16 12:53:50, Jens Axboe wrote:
2) As far as I can see in patch 8/8, you have plugged the throttling above
the IO scheduler. When there are e.g. multiple
On Tue 03-05-16 08:23:27, Jens Axboe wrote:
> On 05/03/2016 03:34 AM, Jan Kara wrote:
> >On Thu 28-04-16 12:53:50, Jens Axboe wrote:
> >>>2) As far as I can see in patch 8/8, you have plugged the throttling above
> >>>the IO scheduler. When there are e.g. multiple cgroups with different
> >>>
On Tue 03-05-16 08:23:27, Jens Axboe wrote:
> On 05/03/2016 03:34 AM, Jan Kara wrote:
> >On Thu 28-04-16 12:53:50, Jens Axboe wrote:
> >>>2) As far as I can see in patch 8/8, you have plugged the throttling above
> >>>the IO scheduler. When there are e.g. multiple cgroups with different
> >>>
On 05/03/2016 03:34 AM, Jan Kara wrote:
On Thu 28-04-16 12:53:50, Jens Axboe wrote:
2) As far as I can see in patch 8/8, you have plugged the throttling above
the IO scheduler. When there are e.g. multiple cgroups with different IO
limits operating, this throttling can lead to strange
On 05/03/2016 03:34 AM, Jan Kara wrote:
On Thu 28-04-16 12:53:50, Jens Axboe wrote:
2) As far as I can see in patch 8/8, you have plugged the throttling above
the IO scheduler. When there are e.g. multiple cgroups with different IO
limits operating, this throttling can lead to strange
On Thu 28-04-16 12:53:50, Jens Axboe wrote:
> >2) As far as I can see in patch 8/8, you have plugged the throttling above
> >the IO scheduler. When there are e.g. multiple cgroups with different IO
> >limits operating, this throttling can lead to strange results (like a
> >cgroup with
On Thu 28-04-16 12:53:50, Jens Axboe wrote:
> >2) As far as I can see in patch 8/8, you have plugged the throttling above
> >the IO scheduler. When there are e.g. multiple cgroups with different IO
> >limits operating, this throttling can lead to strange results (like a
> >cgroup with
On 04/28/2016 12:53 PM, Jens Axboe wrote:
Probably the comment could explain more of "why we do this?" than pure
"what we do".
Agree, if you find it confusing, then it needs updating. I'll update the
comment.
http://git.kernel.dk/cgit/linux-block/commit/?h=wb-buf-throttle
This should
On 04/28/2016 12:53 PM, Jens Axboe wrote:
Probably the comment could explain more of "why we do this?" than pure
"what we do".
Agree, if you find it confusing, then it needs updating. I'll update the
comment.
http://git.kernel.dk/cgit/linux-block/commit/?h=wb-buf-throttle
This should
On 04/28/2016 05:05 AM, Jan Kara wrote:
I have some comments below...
+struct rq_wb {
+ /*
+* Settings that govern how we throttle
+*/
+ unsigned int wb_background; /* background writeback */
+ unsigned int wb_normal; /* normal
On 04/28/2016 05:05 AM, Jan Kara wrote:
I have some comments below...
+struct rq_wb {
+ /*
+* Settings that govern how we throttle
+*/
+ unsigned int wb_background; /* background writeback */
+ unsigned int wb_normal; /* normal
On Tue 26-04-16 09:55:30, Jens Axboe wrote:
> We can hook this up to the block layer, to help throttle buffered
> writes. Or NFS can tap into it, to accomplish the same.
>
> wbt registers a few trace points that can be used to track what is
> happening in the system:
>
> wbt_lat: 259:0: latency
On Tue 26-04-16 09:55:30, Jens Axboe wrote:
> We can hook this up to the block layer, to help throttle buffered
> writes. Or NFS can tap into it, to accomplish the same.
>
> wbt registers a few trace points that can be used to track what is
> happening in the system:
>
> wbt_lat: 259:0: latency
于 2016/4/27 23:21, Jens Axboe 写道:
> On 04/27/2016 06:06 AM, xiakaixu wrote:
>>> +void __wbt_done(struct rq_wb *rwb)
>>> +{
>>> +int inflight, limit = rwb->wb_normal;
>>> +
>>> +/*
>>> + * If the device does write back caching, drop further down
>>> + * before we wake people up.
>>>
于 2016/4/27 23:21, Jens Axboe 写道:
> On 04/27/2016 06:06 AM, xiakaixu wrote:
>>> +void __wbt_done(struct rq_wb *rwb)
>>> +{
>>> +int inflight, limit = rwb->wb_normal;
>>> +
>>> +/*
>>> + * If the device does write back caching, drop further down
>>> + * before we wake people up.
>>>
On 04/27/2016 06:06 AM, xiakaixu wrote:
+void __wbt_done(struct rq_wb *rwb)
+{
+ int inflight, limit = rwb->wb_normal;
+
+ /*
+* If the device does write back caching, drop further down
+* before we wake people up.
+*/
+ if (rwb->wc &&
On 04/27/2016 06:06 AM, xiakaixu wrote:
+void __wbt_done(struct rq_wb *rwb)
+{
+ int inflight, limit = rwb->wb_normal;
+
+ /*
+* If the device does write back caching, drop further down
+* before we wake people up.
+*/
+ if (rwb->wc &&
> + return rwb && rwb->wb_normal != 0;
> +}
> +
> +/*
> + * Increment 'v', if 'v' is below 'below'. Returns true if we succeeded,
> + * false if 'v' + 1 would be bigger than 'below'.
> + */
> +static bool atomic_inc_below(atomic_t *v, int below)
> +{
> + int cur = atomic_read(v);
> +
> +
> + return rwb && rwb->wb_normal != 0;
> +}
> +
> +/*
> + * Increment 'v', if 'v' is below 'below'. Returns true if we succeeded,
> + * false if 'v' + 1 would be bigger than 'below'.
> + */
> +static bool atomic_inc_below(atomic_t *v, int below)
> +{
> + int cur = atomic_read(v);
> +
> +
We can hook this up to the block layer, to help throttle buffered
writes. Or NFS can tap into it, to accomplish the same.
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,
We can hook this up to the block layer, to help throttle buffered
writes. Or NFS can tap into it, to accomplish the same.
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,
40 matches
Mail list logo
