Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933700AbaD2Ku1 (ORCPT ); Tue, 29 Apr 2014 06:50:27 -0400 Received: from forward-corp1f.mail.yandex.net ([95.108.130.40]:53557 "EHLO forward-corp1f.mail.yandex.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933543AbaD2KuZ (ORCPT ); Tue, 29 Apr 2014 06:50:25 -0400 From: Roman Gushchin To: Greg Thelen Cc: Michal Hocko , Johannes Weiner , Andrew Morton , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Michel Lespinasse , Tejun Heo , Hugh Dickins , LKML , "linux-mm@kvack.org" In-Reply-To: References: <1398688005-26207-1-git-send-email-mhocko@suse.cz> <10861398700008@webcorp2f.yandex-team.ru> Subject: Re: [PATCH v2 0/4] memcg: Low-limit reclaim MIME-Version: 1.0 Message-Id: <7441398768618@webcorp2f.yandex-team.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Tue, 29 Apr 2014 14:50:18 +0400 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 29.04.2014, 11:42, "Greg Thelen" : > On Mon, Apr 28 2014, Roman Gushchin wrote: > >> ?28.04.2014, 16:27, "Michal Hocko" : >>> ?The series is based on top of the current mmotm tree. Once the series >>> ?gets accepted I will post a patch which will mark the soft limit as >>> ?deprecated with a note that it will be eventually dropped. Let me know >>> ?if you would prefer to have such a patch a part of the series. >>> >>> ?Thoughts? >> ?Looks good to me. >> >> ?The only question is: are there any ideas how the hierarchy support >> ?will be used in this case in practice? >> ?Will someone set low limit for non-leaf cgroups? Why? >> >> ?Thanks, >> ?Roman > > I imagine that a hosting service may want to give X MB to a top level > memcg (/a) with sub-jobs (/a/b, /a/c) which may(not) have their own > low-limits. > > Examples: > > case_1) only set low limit on /a. ?/a/b and /a/c may overcommit /a's > ????????memory (b.limit_in_bytes + c.limit_in_bytes > a.limit_in_bytes). > > case_2) low limits on all memcg. ?But not overcommitting low_limits > ????????(b.low_limit_in_in_bytes + c.low_limit_in_in_bytes <= > ????????a.low_limit_in_in_bytes). Thanks! With use_hierarchy turned on it looks perfectly usable. -- 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/