Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933620AbbLOUW6 (ORCPT ); Tue, 15 Dec 2015 15:22:58 -0500 Received: from gum.cmpxchg.org ([85.214.110.215]:49976 "EHLO gum.cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932190AbbLOUW5 (ORCPT ); Tue, 15 Dec 2015 15:22:57 -0500 Date: Tue, 15 Dec 2015 15:22:35 -0500 From: Johannes Weiner To: Michal Hocko Cc: Vladimir Davydov , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2 Message-ID: <20151215202235.GB15672@cmpxchg.org> References: <265d8fe623ed2773d69a26d302eb31e335377c77.1449742560.git.vdavydov@virtuozzo.com> <20151214153037.GB4339@dhcp22.suse.cz> <20151214194258.GH28521@esperanza> <20151215172127.GC27880@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151215172127.GC27880@dhcp22.suse.cz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2676 Lines: 47 On Tue, Dec 15, 2015 at 06:21:28PM +0100, Michal Hocko wrote: > > AFAICS such anon memory protection has a side-effect: real-life > > workloads need page cache to run smoothly (at least for mapping > > executables). Disabling swapping would switch pressure to page caches, > > resulting in performance degradation. So, I don't think per memcg swap > > limit can be abused to boost your workload on an overcommitted system. > > Well, you can trash on the page cache which could slow down the workload > but the executable pages get an additional protection so this might be > not sufficient and still trigger a massive disruption on the global level. No, this is a real consequence. If you fill your available memory with mostly unreclaimable memory and your executables start thrashing you might not make forward progress for hours. We don't have a swap token for page cache. > Just to make it clear. I am not against the new way of the swap > accounting. It is much more clear then the previous one. I am just > worried it allows for an easy misconfiguration and we do not have any > measures to help the global system healthiness. I am OK with the patch > if we document the risk for now. I still think we will end up doing some > heuristic to throttle for a large unreclaimable high limit excess in the > future but I agree this shouldn't be the prerequisite. It's unclear to me how the previous memory+swap counters did anything tangible for global system health with malicious/buggy workloads. If anything, the previous model seems to encourage blatant overcommit of workloads on the flawed assumption that global pressure could always claw back memory, including anonymous pages of untrusted workloads, which does not actually work in practice. So I'm not sure what new risk you are referring to here. As far as the high limit goes, its job is to contain cache growth and throttle applications during somewhat higher-than-expected consumption peaks; not to contain "large unreclaimable high limit excess" from buggy or malicious applications, that's what the hard limit is for. All in all, it seems to me we should leave this discussion to actual problems arising in the real world. There is a lot of unfocussed speculation in this thread about things that might go wrong, without much thought put into whether these scenarios are even meaningful or real or whether they are new problems that come with the swap limit. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/