linux-kernel - Re: [RFC v2 0/5] introduce gcma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.10.1502251403390.23105@hxeon>
Date:	Wed, 25 Feb 2015 14:31:08 +0900 (KST)
From:	SeongJae Park <sj38.park@...il.com>
To:	Michal Hocko <mhocko@...e.cz>
cc:	SeongJae Park <sj38.park@...il.com>, akpm@...ux-foundation.org,
	lauraa@...eaurora.org, minchan@...nel.org,
	sergey.senozhatsky@...il.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC v2 0/5] introduce gcma

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.

Current implementation gives selection of policy per cma area to users. 
Only about 120 lines of code were changed for that though it's most ugly 
part of this patch. The part remains as ugly in this RFC because this is 
just prototype. The part will be changed in next version patchset.

>
> For starter something like the following policies should suffice AFAIU
> your description.
> 	- NONE - exclusive pool for CMA allocations only
> 	- DROPABLE - only allocations which might be dropped without any
> 	  additional actions - e.g. cleancache and frontswap with
> 	  write-through policy
> 	- RECLAIMABLE - only movable allocations which can be migrated
> 	  or dropped after writeback.
>
> Has such an approach been considered?

Similarly, but not in same way. In summary, GCMA gives DROPABLE and 
RECLAIMABLE policy selection per cma area and NONE policy to entire cma 
area declared using GCMA interface.

In detail, user could set policy of cma area as gcma way(DROPABLE) or cma 
way(RECLAIMABLE). Also, user could set gcma to utilize their cma area with 
Cleancache and/or Frontswap or not(NONE policy).

Your suggestion looks simple and better to understand. Next version of 
gcma will let users to be able to select policy as those per cma area.

Thanks,
SeongJae Park

> -- 
> Michal Hocko
> SUSE Labs
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/