From: zhouxianrong <zhouxianrong@huawei.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Zhouxiyu <zhouxiyu@huawei.com>,
"wanghaijun (E)" <wanghaijun5@huawei.com>,
"Yuchao (T)" <yuchao0@huawei.com>
Subject: 答复: [PATCH] reusing of mapping page supplies a way for file page allocation under low memory due to pagecache over size and is controlled by sysctl parameters. it is used only for rw page allocation rather than fault or readahead allocation. it is like...
Date: Tue, 31 May 2016 13:35:37 +0000 [thread overview]
Message-ID: <AE94847B1D9E864B8593BD8051012AF36D70EA02@SZXEML505-MBS.china.huawei.com> (raw)
In-Reply-To: <20160531093631.GH26128@dhcp22.suse.cz>
Hey :
the consideration of this patch is that reusing mapping page rather than allocating a new page for page cache when system be placed in some states.
For lookup pages quickly add a new tag PAGECACHE_TAG_REUSE for radix tree which tag the pages that is suitable for reusing.
A page suitable for reusing within mapping is
1. clean
2. map count is zero
3. whose mapping is evictable
A page tagged as PAGECACHE_TAG_REUSE when
1. after writeback a page within end_page_writeback setting the page as PAGECACHE_TAG_REUSE
2. in generic vfs read path default to setting page as PAGECACHE_TAG_REUSE
A page cleared PAGECACHE_TAG_REUSE when
1. page become diry within __set_page_dirty and __set_page_dirty_nobuffers (dirty page is not suitable for reusing)
The steps of resuing a page is
1. invalid a page by invalidate_inode_page (remove form mapping)
2. isolate from lru list by isolate_lru_page
3. clear page uptodate and other page flags
How to startup the functional
1. the system is under low memory state and there are fs rw operations
2. page cache size is get bigger over sysctl limit
If a filesystem wanted to introduce this functional, for example ext4, do like below:
static const struct address_space_operations ext4_aops = {
...
.readpage = ext4_readpage,
.readpages = ext4_readpages,
.writepage = ext4_writepage,
.write_begin = ext4_write_begin,
.write_end = ext4_write_end,
...
.reuse_mapping_page = generic_reuse_mapping_page,
};
-----邮件原件-----
发件人: Michal Hocko [mailto:mhocko@kernel.org]
发送时间: 2016年5月31日 17:37
收件人: zhouxianrong
抄送: viro@zeniv.linux.org.uk; linux-fsdevel@vger.kernel.org; linux-mm@kvack.org; Zhouxiyu; wanghaijun (E); Yuchao (T)
主题: Re: [PATCH] reusing of mapping page supplies a way for file page allocation under low memory due to pagecache over size and is controlled by sysctl parameters. it is used only for rw page allocation rather than fault or readahead allocation. it is like...
On Tue 31-05-16 17:08:22, zhouxianrong@huawei.com wrote:
> From: z00281421 <z00281421@notesmail.huawei.com>
>
> const struct address_space_operations special_aops = {
> ...
> .reuse_mapping_page = generic_reuse_mapping_page, }
Please try to write a proper changelog which explains what is the change, why do we need it and who is it going to use.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2016-05-31 13:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-31 9:08 [PATCH] reusing of mapping page supplies a way for file page allocation under low memory due to pagecache over size and is controlled by sysctl parameters. it is used only for rw page allocation rather than fault or readahead allocation. it is like relclaim but is lighter than reclaim. it only reuses clean and zero mapcount pages of mapping. for special filesystems using this feature like below: zhouxianrong
2016-05-31 9:36 ` Michal Hocko
2016-05-31 13:35 ` zhouxianrong [this message]
2016-05-31 14:03 ` 答复: [PATCH] reusing of mapping page supplies a way for file page allocation under low memory due to pagecache over size and is controlled by sysctl parameters. it is used only for rw page allocation rather than fault or readahead allocation. it is like Michal Hocko
2016-06-01 1:52 ` zhouxianrong
2016-06-01 8:18 ` Michal Hocko
2016-06-01 9:06 ` zhouxianrong
2016-06-01 9:49 ` Michal Hocko
2016-06-01 9:56 ` zhouxianrong
2016-06-01 9:28 ` zhouxianrong
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=AE94847B1D9E864B8593BD8051012AF36D70EA02@SZXEML505-MBS.china.huawei.com \
--to=zhouxianrong@huawei.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=wanghaijun5@huawei.com \
--cc=yuchao0@huawei.com \
--cc=zhouxiyu@huawei.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