From: Theodore Ts'o <tytso@mit.edu>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Gioh Kim <gioh.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
jack@suse.cz, linux-fsdevel@vger.kernel.org,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
viro@zeniv.linux.org.uk, paulmck@linux.vnet.ibm.com,
peterz@infradead.org, adilger.kernel@dilger.ca,
minchan@kernel.org, gunho.lee@lge.com
Subject: Re: [PATCHv4 0/3] new APIs to allocate buffer-cache with user specific flag
Date: Fri, 5 Sep 2014 10:14:16 -0400 [thread overview]
Message-ID: <20140905141416.GA1510@thunk.org> (raw)
In-Reply-To: <20140905073247.GA31827@js1304-P5Q-DELUXE>
On Fri, Sep 05, 2014 at 04:32:48PM +0900, Joonsoo Kim wrote:
> I also test another approach, such as allocate freepage in CMA
> reserved region as late as possible, which is also similar to your
> suggestion and this doesn't works well. When reclaim is started,
> too many pages reclaim at once, because lru list has successive pages
> in CMA region and these doesn't help kswapd's reclaim. kswapd stop
> reclaiming when freepage count is recovered. But, CMA pages isn't
> counted for freepage for kswapd because they can't be usable for
> unmovable, reclaimable allocation. So kswap reclaim too many pages
> at once unnecessarilly.
Have you considered putting the pages in a CMA region in a separate
zone? After all, that's what we originally did with brain-damaged
hardware that could only DMA into the low 16M of memory. We just
reserved a separate zone for that? That way, we could do
zone-directed reclaim and free pages in that zone, if that was what
was actually needed.
But if we would also preferentially avoid using pages from that zone
unless there was no choice, in order to avoid needing to do that
zone-directed reclaim. Perhaps a similar solution could do done here?
- Ted
next prev parent reply other threads:[~2014-09-05 14:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1409815781-28011-1-git-send-email-gioh.kim@lge.com>
2014-09-04 22:16 ` [PATCHv4 0/3] new APIs to allocate buffer-cache with user specific flag Andrew Morton
2014-09-05 0:37 ` Gioh Kim
2014-09-05 1:14 ` Theodore Ts'o
2014-09-05 1:48 ` Joonsoo Kim
2014-09-05 3:17 ` Theodore Ts'o
2014-09-05 7:32 ` Joonsoo Kim
2014-09-05 14:14 ` Theodore Ts'o [this message]
2014-09-15 1:10 ` Joonsoo Kim
2014-09-15 6:37 ` Minchan Kim
[not found] ` <1409815781-28011-2-git-send-email-gioh.kim@lge.com>
2014-09-05 2:37 ` [PATCHv4 1/3] fs.c: support buffer cache allocations with gfp modifiers Theodore Ts'o
[not found] ` <1409815781-28011-3-git-send-email-gioh.kim@lge.com>
2014-09-05 2:37 ` [PATCHv4 2/3] ext4: use non-movable memory for the ext4 superblock Theodore Ts'o
[not found] ` <1409815781-28011-4-git-send-email-gioh.kim@lge.com>
2014-09-05 2:37 ` [PATCHv4 3/3] jbd/jbd2: use non-movable memory for the jbd superblock Theodore Ts'o
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=20140905141416.GA1510@thunk.org \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=gioh.kim@lge.com \
--cc=gunho.lee@lge.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=minchan@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=viro@zeniv.linux.org.uk \
/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).