On Wed, 25 Feb 2015, Michal Hocko wrote:
On Wed 25-02-15 14:31:08, SeongJae Park wrote:
Hello Michal,
Thanks for your comment :)
On Tue, 24 Feb 2015, Michal Hocko wrote:
On Tue 24-02-15 04:54:18, SeongJae Park wrote:
[...]
include/linux/cma.h | 4 +
include/linux/gcma.h | 64 +++
mm/Kconfig | 24 +
mm/Makefile | 1 +
mm/cma.c | 113 ++++-
mm/gcma.c | 1321 ++++++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 1508 insertions(+), 19 deletions(-)
create mode 100644 include/linux/gcma.h
create mode 100644 mm/gcma.c
Wow this is huge! And I do not see reason for it to be so big. Why
cannot you simply define (per-cma area) 2-class users policy? Either via
kernel command line or export areas to userspace and allow to set policy
there.
For implementation of the idea, we should develop not only policy selection,
but also backend for discardable memory. Most part of this patch were made
for the backend.
What is the backend and why is it needed? I thought the discardable will
go back to the CMA pool. I mean the cover email explained why the
current CMA allocation policy might lead to lower success rate or
stalls. So I would expect a new policy would be a relatively small
change in the CMA allocation path to serve 2-class users as per policy.
It is not clear to my why we need to pull a whole gcma layer in. I might
be missing something obvious because I haven't looked at the patches yet
but this should better be explained in the cover letter.
I meant backend for 2nd-class clients like cleancache and frontswap.
Because implementing backend for cleancache or frontswap is subsystem's
responsibility, gcma was needed to implement those backend. I believe
second ("gcma: utilize reserved memory as discardable memory") and
third ("gcma: adopt cleancache and frontswap as second-class
clients") could be helpful to understand about that.
And yes, I agree the explanation was not enough. My fault, sorry. My
explanation was too concentrated on policy itself. I should explained
about how the policy could be implemented and how gcma did. I will explain
about that in coverletter with next version.
Thanks for your helpful and nice comment.
Thanks,
SeongJae Park
Thanks!
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>