From: Maxim Patlasov <mpatlasov@parallels.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: <fuse-devel@lists.sourceforge.net>,
<linux-fsdevel@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/4] fuse: writepage: update bdi writeout when deleting secondary request
Date: Thu, 3 Oct 2013 17:46:05 +0400 [thread overview]
Message-ID: <524D751D.90007@parallels.com> (raw)
In-Reply-To: <20131003102614.GC14242@tucsk.piliscsaba.szeredi.hu>
On 10/03/2013 02:26 PM, Miklos Szeredi wrote:
> On Wed, Oct 02, 2013 at 09:38:43PM +0400, Maxim Patlasov wrote:
>> BDI_WRITTEN counter is used to estimate bdi bandwidth. It must be incremented
>> every time as bdi ends page writeback. No matter whether it was fulfilled by
>> actual write or by discarding the request (e.g. due to shrunk i_size).
>>
>> Note that even before writepages patches, the case "Got truncated off
>> completely" was handled in fuse_send_writepage() by calling
>> fuse_writepage_finish() which updated BDI_WRITTEN unconditionally.
> Hmm, I'm not sure I can agree with this. If BDI_WRITTEN is used for bandwidth
> estimation, then I think it's more correct not to count rewrites and truncated
> pages.
I thought about it before submitting the patch, but my understanding is
a bit different. Look how balance_dirty_pages and friends juggle with
BDI_WRITTEN and BDI_DIRTIED. That layer knows nothing about fuse and its
internals. Imagine that right now (if actual backend throughput is about
10MB/sec) you believe that dirtying 26 pages per 10 milliseconds is
fine, but when they lapsed you discovers that BDI_DIRTIED delta is 26
while BDI_WRITTEN delta is only 13. Logically, you must decide to cut
dirty-rate by factor two, but the decision would be incorrect in case of
unaccounted truncated rewrites.
>
> But I don't see this matter either way since this is just used as a heuristic
> and the occasional extra or lack of count shouldn't make a significant
> difference.
I agree, but for another reason. I think it won't make a significant
difference because rewrites coinciding with writebacks coinciding with
truncations will happen very rare in real life.
Thanks,
Maxim
>
> Thanks,
> Miklos
>
>> Signed-off-by: Maxim Patlasov <MPatlasov@parallels.com>
>> ---
>> fs/fuse/file.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
>> index a3c7123..5d323bd 100644
>> --- a/fs/fuse/file.c
>> +++ b/fs/fuse/file.c
>> @@ -1536,6 +1536,7 @@ static void fuse_writepage_end(struct fuse_conn *fc, struct fuse_req *req)
>> drop->inode->i_mapping->backing_dev_info;
>> dec_bdi_stat(bdi, BDI_WRITEBACK);
>> dec_zone_page_state(drop->pages[0], NR_WRITEBACK_TEMP);
>> + bdi_writeout_inc(bdi);
>> fuse_writepage_free(fc, drop);
>> fuse_put_request(fc, drop);
>> drop = next;
>> @@ -1706,11 +1707,14 @@ static bool fuse_writepage_in_flight(struct fuse_req *new_req,
>>
>> if (old_req->num_pages == 1 && (old_req->state == FUSE_REQ_INIT ||
>> old_req->state == FUSE_REQ_PENDING)) {
>> + struct backing_dev_info *bdi = page->mapping->backing_dev_info;
>> +
>> copy_highpage(old_req->pages[0], page);
>> spin_unlock(&fc->lock);
>>
>> - dec_bdi_stat(page->mapping->backing_dev_info, BDI_WRITEBACK);
>> + dec_bdi_stat(bdi, BDI_WRITEBACK);
>> dec_zone_page_state(page, NR_WRITEBACK_TEMP);
>> + bdi_writeout_inc(bdi);
>> fuse_writepage_free(fc, new_req);
>> fuse_request_free(new_req);
>> goto out;
>>
>
next prev parent reply other threads:[~2013-10-03 13:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-02 17:37 [PATCH 0/4] fuse: fixes for fuse_writepage_in_flight() and friends -v2 Maxim Patlasov
2013-10-02 17:38 ` [PATCH 1/4] fuse: writepages: roll back changes if request not found Maxim Patlasov
2013-10-02 17:38 ` [PATCH 2/4] fuse: writepages: crop secondary requests Maxim Patlasov
2013-10-03 9:57 ` Miklos Szeredi
2013-10-03 13:28 ` Maxim Patlasov
2013-10-03 15:14 ` Miklos Szeredi
2013-10-03 15:50 ` Maxim Patlasov
2013-10-03 16:09 ` Miklos Szeredi
2013-10-03 16:22 ` Maxim Patlasov
2013-10-09 8:20 ` [fuse-devel] " Maxim Patlasov
2013-10-09 15:37 ` Maxim Patlasov
2013-10-02 17:38 ` [PATCH 3/4] fuse: writepage: update bdi writeout when deleting secondary request Maxim Patlasov
2013-10-03 10:26 ` Miklos Szeredi
2013-10-03 13:46 ` Maxim Patlasov [this message]
2013-10-02 17:38 ` [PATCH 4/4] fuse: writepages: protect secondary requests from fuse file release Maxim Patlasov
2013-10-03 10:33 ` Miklos Szeredi
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=524D751D.90007@parallels.com \
--to=mpatlasov@parallels.com \
--cc=fuse-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.