Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751990AbaL2Irh (ORCPT ); Mon, 29 Dec 2014 03:47:37 -0500 Received: from mx2.parallels.com ([199.115.105.18]:51494 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750994AbaL2Irg (ORCPT ); Mon, 29 Dec 2014 03:47:36 -0500 Date: Mon, 29 Dec 2014 11:47:28 +0300 From: Vladimir Davydov To: Johannes Weiner CC: , Michal Hocko , Greg Thelen , Tejun Heo , Andrew Morton , Subject: Re: [RFC PATCH 1/2] memcg: account swap instead of memory+swap Message-ID: <20141229084728.GB9984@esperanza> References: <20141228190020.GA9385@phnom.home.cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20141228190020.GA9385@phnom.home.cmpxchg.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Dec 28, 2014 at 02:00:20PM -0500, Johannes Weiner wrote: > On Sun, Dec 28, 2014 at 07:19:12PM +0300, Vladimir Davydov wrote: > > The design of swap limits for memory cgroups looks broken. Instead of a > > separate swap limit, there is the memory.memsw.limit_in_bytes knob, > > which limits total memory+swap consumption. As a result, under global > > memory pressure, a cgroup can eat up to memsw.limit of *swap*, so it's > > just impossible to set the swap limit to be less than the memory limit > > with such a design. In particular, this means that we have to leave swap > > unlimited if we want to partition system memory dynamically using soft > > limits. > > > > This patch therefore attempts to move from memory+swap to pure swap > > accounting so that we will be able to separate memory and swap resources > > in the sane cgroup hierarchy, which is the business of the following > > patch. > > > > The old interface acts on memory and swap limits as follows: > > The implementation seems fine to me, but there is no point in cramming > this into the old interface. Let's just leave it alone and implement > proper swap accounting and limiting in the default/unified hierarchy. Agree - the patch will be cleaner, and we won't need to bother about compatibility issues then. Thanks, Vladimir -- 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/