From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752351AbbBYF20 (ORCPT ); Wed, 25 Feb 2015 00:28:26 -0500 Received: from mail-pa0-f43.google.com ([209.85.220.43]:34130 "EHLO mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751899AbbBYF2Y (ORCPT ); Wed, 25 Feb 2015 00:28:24 -0500 From: SeongJae Park X-Google-Original-From: SeongJae Park Date: Wed, 25 Feb 2015 14:31:08 +0900 (KST) To: Michal Hocko cc: SeongJae Park , akpm@linux-foundation.org, lauraa@codeaurora.org, minchan@kernel.org, sergey.senozhatsky@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC v2 0/5] introduce gcma In-Reply-To: <20150224144804.GE15626@dhcp22.suse.cz> Message-ID: References: <1424721263-25314-1-git-send-email-sj38.park@gmail.com> <20150224144804.GE15626@dhcp22.suse.cz> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >