From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755354AbcFQGnh (ORCPT ); Fri, 17 Jun 2016 02:43:37 -0400 Received: from LGEAMRELO11.lge.com ([156.147.23.51]:48008 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755304AbcFQGnd (ORCPT ); Fri, 17 Jun 2016 02:43:33 -0400 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 165.244.98.203 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Fri, 17 Jun 2016 15:43:30 +0900 From: Minchan Kim To: Johannes Weiner CC: Andrew Morton , , , Rik van Riel , Sangwoo Park Subject: Re: [PATCH v1 3/3] mm: per-process reclaim Message-ID: <20160617064330.GD2374@bbox> References: <1465804259-29345-1-git-send-email-minchan@kernel.org> <1465804259-29345-4-git-send-email-minchan@kernel.org> <20160613150653.GA30642@cmpxchg.org> <20160615004027.GA17127@bbox> <20160616144102.GA17692@cmpxchg.org> MIME-Version: 1.0 In-Reply-To: <20160616144102.GA17692@cmpxchg.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB02/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/06/17 15:43:30, Serialize by Router on LGEKRMHUB02/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/06/17 15:43:30, Serialize complete at 2016/06/17 15:43:30 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Hannes, On Thu, Jun 16, 2016 at 10:41:02AM -0400, Johannes Weiner wrote: > On Wed, Jun 15, 2016 at 09:40:27AM +0900, Minchan Kim wrote: > > A question is it seems cgroup2 doesn't have per-cgroup swappiness. > > Why? > > > > I think we need it in one-cgroup-per-app model. > > Can you explain why you think that? > > As we have talked about this recently in the LRU balancing thread, > swappiness is the cost factor between file IO and swapping, so the > only situation I can imagine you'd need a memcg swappiness setting is > when you have different cgroups use different storage devices that do > not have comparable speeds. > > So I'm not sure I understand the relationship to an app-group model. Sorry for lacking the inforamtion. I should have written more clear. In fact, what we need is *per-memcg-swap-device*. What I want is to avoid kill background application although memory is overflow because cold launcing of app takes a very long time compared to resume(ie, just switching). I also want to keep a mount of free pages in the memory so that new application startup cannot be stuck by reclaim activities. To get free memory, I want to reclaim less important app rather than killing. In this time, we can support two swap devices. A one is zram, other is slow storage but much bigger than zram size. Then, we can use storage swap to reclaim pages for not-important app while we can use zram swap for for important app(e.g., forground app, system services, daemon and so on). IOW, we want to support mutiple swap device with one-cgroup-per-app and the storage speed is totally different.