From: Imre Palik <imrep.amz@gmail.com>
To: Lars <lars.ellenberg@linbit.com>
Cc: drbd-dev@lists.linbit.com,
Philipp Reisner <philipp.reisner@linbit.com>,
linux-kernel@vger.kernel.org, "Palik, Imre" <imrep@amazon.de>,
Matt Wilson <msw@amazon.com>
Subject: Re: [PATCH v3] drbd: fix throttling on newly created DM backing devices
Date: Mon, 08 Sep 2014 15:05:28 +0200 [thread overview]
Message-ID: <540DA998.7060807@gmail.com> (raw)
In-Reply-To: <20140907095834.GA2332@hein>
On 09/07/14 11:58, Lars wrote:
> On Fri, Sep 05, 2014 at 08:41:18PM +0200, Imre Palik wrote:
>> From: "Palik, Imre" <imrep@amazon.de>
>>
>> If the drbd backing device is a new device mapper device (e.g., a
>> dm-linear mapping of an existing block device that contains data), the
>> counters are initially 0 even though the device contains useful
>> data. This causes throttling until something accesses the drbd device
>> or the backing device.
>
> What was wrong with my previous proposal?
Sorry, I haven't realised you added a proposal to your reply. It seems,
I really needed that extra sleep during the weekend ...
Your proposal is good. Of course, I like my last one a slightly better.
But as they say, beauty is in the eye of the beholder :-)
> How does changing the signedness help with
> rs_last_events not being properly initialized?
It only helps with reasoning. I reason with modular arithmetic way
easier than with signed integer overflows. Accidentally, 0 is a good
initialisation value in case of unsigned arithmetic.
> Are you sure you have also considered all wrap-around cases?
>
> Maybe you are too focused on your particular corner case
> (disk_stats starting with 0).
> Maybe I'm just thick right now, so please explain.
The idea is that 0 is the smallest possible value for an unsigned, and
curr_events is monotonically increasing (mod 2^32) . This means,
initially either curr_events > 64, that is, we enter the loop, and do
the initialisation, or it will be bigger than 64 at most when we want to
start throttle in an ideal world (after no more than 64 sectors of
activity).
Basically, while you initialise rs_last_events to an ideal value with
some calculation, I choose a safe static value. I am content with both
approaches. I think, as a subsystem maintainer, you should choose the
one you like better. If you choose yours, then you can add
Reviewed-by: Imre Palik <imrep@amazon.de>
Imre
>
> Lars
>
>> The patch disables throttling, as long as only resync is responsible
>> for disk activity on a freshly created device.
>>
>> Reported-by: Mikhail Sugakov <msugakov@amazon.de>
>> Cc: Matt Wilson <msw@amazon.com>
>> Signed-off-by: Imre Palik <imrep@amazon.de>
>> ---
>> drivers/block/drbd/drbd_int.h | 4 ++--
>> drivers/block/drbd/drbd_receiver.c | 10 +++++-----
>> 2 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/block/drbd/drbd_int.h b/drivers/block/drbd/drbd_int.h
>> index 1a00001..298b1dc 100644
>> --- a/drivers/block/drbd/drbd_int.h
>> +++ b/drivers/block/drbd/drbd_int.h
>> @@ -960,8 +960,8 @@ struct drbd_device {
>> atomic_t rs_sect_in; /* for incoming resync data rate, SyncTarget */
>> atomic_t rs_sect_ev; /* for submitted resync data rate, both */
>> int rs_last_sect_ev; /* counter to compare with */
>> - int rs_last_events; /* counter of read or write "events" (unit sectors)
>> - * on the lower level device when we last looked. */
>> + unsigned int rs_last_events; /* counter of read or write "events" (unit sectors)
>> + * on the lower level device when we last looked. */
>> int c_sync_rate; /* current resync rate after syncer throttle magic */
>> struct fifo_buffer *rs_plan_s; /* correction values of resync planer (RCU, connection->conn_update) */
>> int rs_in_flight; /* resync sectors in flight (to proxy, in proxy and from proxy) */
>> diff --git a/drivers/block/drbd/drbd_receiver.c b/drivers/block/drbd/drbd_receiver.c
>> index 9342b8d..147c917 100644
>> --- a/drivers/block/drbd/drbd_receiver.c
>> +++ b/drivers/block/drbd/drbd_receiver.c
>> @@ -2467,7 +2467,7 @@ bool drbd_rs_c_min_rate_throttle(struct drbd_device *device)
>> struct gendisk *disk = device->ldev->backing_bdev->bd_contains->bd_disk;
>> unsigned long db, dt, dbdt;
>> unsigned int c_min_rate;
>> - int curr_events;
>> + unsigned int curr_events;
>>
>> rcu_read_lock();
>> c_min_rate = rcu_dereference(device->ldev->disk_conf)->c_min_rate;
>> @@ -2477,12 +2477,12 @@ bool drbd_rs_c_min_rate_throttle(struct drbd_device *device)
>> if (c_min_rate == 0)
>> return false;
>>
>> - curr_events = (int)part_stat_read(&disk->part0, sectors[0]) +
>> - (int)part_stat_read(&disk->part0, sectors[1]) -
>> - atomic_read(&device->rs_sect_ev);
>> + curr_events = (unsigned int)part_stat_read(&disk->part0, sectors[0]) +
>> + (unsigned int)part_stat_read(&disk->part0, sectors[1]) -
>> + (unsigned int)atomic_read(&device->rs_sect_ev);
>>
>> if (atomic_read(&device->ap_actlog_cnt)
>> - || !device->rs_last_events || curr_events - device->rs_last_events > 64) {
>> + || curr_events - device->rs_last_events > 64) {
>> unsigned long rs_left;
>> int i;
>>
>> --
>> 1.7.9.5
>>
next prev parent reply other threads:[~2014-09-08 13:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-05 18:41 [PATCH v3] drbd: fix throttling on newly created DM backing devices Imre Palik
2014-09-07 9:58 ` Lars
2014-09-08 13:05 ` Imre Palik [this message]
2014-09-08 13:38 ` Lars
2014-09-09 19:03 ` Imre Palik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=540DA998.7060807@gmail.com \
--to=imrep.amz@gmail.com \
--cc=drbd-dev@lists.linbit.com \
--cc=imrep@amazon.de \
--cc=lars.ellenberg@linbit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=msw@amazon.com \
--cc=philipp.reisner@linbit.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox