linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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: 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...
Date: Wed, 1 Jun 2016 09:52:45 +0800	[thread overview]
Message-ID: <ea553117-3735-fccb-0e7a-e289633cdd9f@huawei.com> (raw)
In-Reply-To: <20160531140354.GM26128@dhcp22.suse.cz>

 >> A page suitable for reusing within mapping is
 >> 1. clean
 >> 2. map count is zero
 >> 3. whose mapping is evictable
 >
 > Those pages are trivially reclaimable so why should we tag them in a
 > special way?
   yes, those pages can be reclaimed by reclaim procedure. i think in low memory
   case for a process that doing file rw directly-reusing-mapping-page may be
   a choice than alloc_page just like directly reclaim. alloc_page could failed return
   due to gfp and watermark in low memory. for reusing-mapping-page procedure quickly
   select a page that is be reused so introduce a tag for this purpose.


 > So is this a form of a page cache limit to trigger the reclaim earlier
 > than on the global memory pressure?
   my thinking is that page cache limit trigger reuse-mapping-page . the limit is earlier than on the global memory pressure.
   reuse-mapping-page can suppress increment of page cache size and big page cache size
   is one reason of low memory and fragment.

On 2016/5/31 22:03, Michal Hocko wrote:
> On Tue 31-05-16 13:35:37, zhouxianrong wrote:
>> 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
>
> Those pages are trivially reclaimable so why should we tag them in a
> special way?
>
> [...]
>
>> 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
>
> So is this a form of a page cache limit to trigger the reclaim earlier
> than on the global memory pressure?
>

--
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:[~2016-06-01  1:54 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   ` 答复: [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 zhouxianrong
2016-05-31 14:03     ` Michal Hocko
2016-06-01  1:52       ` zhouxianrong [this message]
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=ea553117-3735-fccb-0e7a-e289633cdd9f@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