From: SeongJae Park <sj38.park@gmail.com>
To: Christoph Lameter <cl@linux.com>
Cc: SeongJae Park <sj38.park@gmail.com>,
akpm@linux-foundation.org, lauraa@codeaurora.org,
minchan@kernel.org, sergey.senozhatsky@gmail.com,
linux-mm@kvack.org
Subject: Re: [RFC v1 0/6] introduce gcma
Date: Wed, 12 Nov 2014 16:02:43 +0900 (KST) [thread overview]
Message-ID: <alpine.DEB.2.10.1411121549300.18607@hxeon> (raw)
In-Reply-To: <alpine.DEB.2.11.1411111255420.6657@gentwo.org>
Hi Christoph,
On Tue, 11 Nov 2014, Christoph Lameter wrote:
> On Wed, 12 Nov 2014, SeongJae Park wrote:
>
>> Difference with cma is choice and operation of 2nd-class client. In gcma,
>> 2nd-class client should allocate pages from the reserved area only if the
>> allocated pages mets following conditions.
>
> How about making CMA configurable in some fashion to be able to specify
> the type of 2nd class clients? Clean page-cache pages can also be rather
> easily evicted (see zone-reclaim). You could migrate them out when they
> are dirtied so that you do not have the high writeback latency from the
> CMA reserved area if it needs to be evicted later.
Nice point.
Currently, gcma is integrated inside cma and user could decide a specific
contiguous memory area to work in cma way(movable pages as 2nd class) or
in gcma way(out-of-kernel, easy-to-discard pages as 2nd class).
It is implemented in 6th change of this RFC, "gcma: integrate gcma under
cma interface".
In short, the 2nd-clients of cma is already configurable between
movable pages and frontswap backend with this RFC.
And yes, cleancache will be great 2nd class client.
As described within coverletter, our 2nd class client candidates are
frontswap and _cleancache_. But, because the gcma is still in unmatured
sate yet, current RFC(this patchset) use only frontswap.
In future, it will be configurable.
Apologize I forgot to describe about future plan.
Thanks,
SeongJae Park
>
>
--
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>
prev parent reply other threads:[~2014-11-12 7:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-11 15:00 SeongJae Park
2014-11-11 15:00 ` [RFC v1 1/6] gcma: introduce contiguous memory allocator SeongJae Park
2014-11-11 15:00 ` [RFC v1 2/6] gcma: utilize reserved memory as swap cache SeongJae Park
2014-11-11 15:00 ` [RFC v1 3/6] gcma: evict frontswap pages in LRU order when memory is full SeongJae Park
2014-11-11 15:00 ` [RFC v1 4/6] gcma: discard swap cache pages to meet successful GCMA allocation SeongJae Park
2014-11-11 15:00 ` [RFC v1 5/6] gcma: export statistical data on debugfs SeongJae Park
2014-11-11 15:00 ` [RFC v1 6/6] gcma: integrate gcma under cma interface SeongJae Park
2014-11-11 18:57 ` [RFC v1 0/6] introduce gcma Christoph Lameter
2014-11-12 7:02 ` SeongJae Park [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=alpine.DEB.2.10.1411121549300.18607@hxeon \
--to=sj38.park@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=lauraa@codeaurora.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=sergey.senozhatsky@gmail.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