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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).