linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Maxim V. Patlasov" <mpatlasov@parallels.com>
To: Jaegeuk Hanse <jaegeuk.hanse@gmail.com>
Cc: miklos@szeredi.hu, dev@parallels.com, xemul@parallels.com,
	fuse-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
	jbottomley@parallels.com, linux-mm@kvack.org,
	viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 14/14] mm: Account for WRITEBACK_TEMP in balance_dirty_pages
Date: Thu, 22 Nov 2012 17:56:01 +0400	[thread overview]
Message-ID: <50AE2EF1.4080904@parallels.com> (raw)
In-Reply-To: <50AE2842.3060509@gmail.com>

Hi,

11/22/2012 05:27 PM, Jaegeuk Hanse пишет:
> On 11/21/2012 08:01 PM, Maxim Patlasov wrote:
>> Added linux-mm@ to cc:. The patch can stand on it's own.
>>
>>> Make balance_dirty_pages start the throttling when the WRITEBACK_TEMP
>>> counter is high enough. This prevents us from having too many dirty
>>> pages on fuse, thus giving the userspace part of it a chance to write
>>> stuff properly.
>>>
>>> Note, that the existing balance logic is per-bdi, i.e. if the fuse
>>> user task gets stuck in the function this means, that it either
>>> writes to the mountpoint it serves (but it can deadlock even without
>>> the writeback) or it is writing to some _other_ dirty bdi and in the
>>> latter case someone else will free the memory for it.
>> Signed-off-by: Maxim V. Patlasov <MPatlasov@parallels.com>
>> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>> ---
>>   mm/page-writeback.c |    3 ++-
>>   1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
>> index 830893b..499a606 100644
>> --- a/mm/page-writeback.c
>> +++ b/mm/page-writeback.c
>> @@ -1220,7 +1220,8 @@ static void balance_dirty_pages(struct 
>> address_space *mapping,
>>            */
>>           nr_reclaimable = global_page_state(NR_FILE_DIRTY) +
>>                       global_page_state(NR_UNSTABLE_NFS);
>> -        nr_dirty = nr_reclaimable + global_page_state(NR_WRITEBACK);
>> +        nr_dirty = nr_reclaimable + global_page_state(NR_WRITEBACK) +
>> +            global_page_state(NR_WRITEBACK_TEMP);
>
> Could you explain NR_WRITEBACK_TEMP is used for accounting what? And 
> when it will increase?

The only user of NR_WRITEBACK_TEMP is fuse. Handling .writepage it:

1) allocates new page
2) copies original page (that came to .writepage as argument) to new page
3) attaches new page to fuse request
4) increments NR_WRITEBACK_TEMP
5) does end_page_writeback on original page
6) schedules fuse request for processing

Later, fuse request will be send to userspace, then userspace will 
process it and ACK it to kernel fuse. Processing this ACK from 
userspace, in-kernel fuse will free that new page and decrement 
NR_WRITEBACK_TEMP.

So, effectively, NR_WRITEBACK_TEMP keeps track of pages which are under 
'fuse writeback'.

Thanks,
Maxim

>
>> global_dirty_limits(&background_thresh, &dirty_thresh);
>>
>> -- 
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majordomo@kvack.org.  For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
>
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2012-11-22 13:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20121116171039.3196.92186.stgit@maximpc.sw.ru>
2012-11-21 12:01 ` Maxim Patlasov
2012-11-22 13:27   ` Jaegeuk Hanse
2012-11-22 13:56     ` Maxim V. Patlasov [this message]

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=50AE2EF1.4080904@parallels.com \
    --to=mpatlasov@parallels.com \
    --cc=dev@parallels.com \
    --cc=fuse-devel@lists.sourceforge.net \
    --cc=jaegeuk.hanse@gmail.com \
    --cc=jbottomley@parallels.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=miklos@szeredi.hu \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xemul@parallels.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