All of lore.kernel.org
 help / color / mirror / Atom feed
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;
>>
>

  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.