From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A34EEC3F2CD for ; Thu, 5 Mar 2020 14:55:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 600E820732 for ; Thu, 5 Mar 2020 14:55:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="AQZExFJC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 600E820732 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F07BC6B0003; Thu, 5 Mar 2020 09:55:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EB8306B0005; Thu, 5 Mar 2020 09:55:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DCD0D6B0007; Thu, 5 Mar 2020 09:55:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0067.hostedemail.com [216.40.44.67]) by kanga.kvack.org (Postfix) with ESMTP id C3BBB6B0003 for ; Thu, 5 Mar 2020 09:55:57 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C5E27180AD801 for ; Thu, 5 Mar 2020 14:55:57 +0000 (UTC) X-FDA: 76561608354.24.mask38_16e6624360828 X-HE-Tag: mask38_16e6624360828 X-Filterd-Recvd-Size: 5547 Received: from mail-qk1-f196.google.com (mail-qk1-f196.google.com [209.85.222.196]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Thu, 5 Mar 2020 14:55:57 +0000 (UTC) Received: by mail-qk1-f196.google.com with SMTP id e11so5511065qkg.9 for ; Thu, 05 Mar 2020 06:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=NOWIJylcLM+2xBd7NFNAk6brzU5tY0Fsm0nPExtQlys=; b=AQZExFJChAVsycjeW1vn8E/eFNQMwIQ/E1wOUbJyXyiI7yqeIO52aTGC2JoIicCOWZ 1sUUROklG3EgdcJcdNxYI6oMbpXBFf8ZZJ+hBTfk499bLUpDrfe9aAm7NLl5daPr7MU1 RlJ5LVkWr9PIBuZCoyWeiLsYf01bEW0/XfhNuL2n8J6BvqrYhd4C6dVjBnQDKjL7CVr2 2iOP180GVHMGCeecqmRHLea0owluRkZIfYwVGJXE5GfQaGslPEOF3A1LVY4loo1c+GOI pxqQE+pv0oJwAhU/UAfSDyRJ/nllwVVp3it4CPf2Xz0zbfa0STQeJv8WIN+tRBFv0tj8 0slQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=NOWIJylcLM+2xBd7NFNAk6brzU5tY0Fsm0nPExtQlys=; b=DWNrlDFrQFmJdw4Jlj8mei/C4j8yRGkAE4mmb6IZX+iDUGCoPRVAfK2TYx8EY9IJjD pXQXRXPHT+bmOZPP1tCqECRvXWVVttkajMB6V1ItCmmiTwFCGML6jCJ2RTpRIfj5Yejn GZYX1UBOuThQgTrpgLkU7EOSs12CYFn3dkx7zCl6XCKnoPtnudKAOMd1Ss9Xi5+r7uu2 QHtmLUwbH67nk867RRxoWt6jUiWHiThqcBjPVOvCxs3mlzrpCEqnJdXkmYGE8jeY55iG PArdtTh4seLOxdjrOSjuL3m6qzeu24WAvTDqSd/MoXyaMvde6BOo8L//L2nsX4jlDLfN e0mQ== X-Gm-Message-State: ANhLgQ0/agcEAgnyWlcFDBCZLxELn2FOxjGQJHlQUiiUq7b6Oacua8RX 1SA5V1RdSoJUdZ7RG9ut+5E= X-Google-Smtp-Source: ADFU+vumIu4nB9uNeFZ8yVvaEoW2zgyv3RZnkrGIJ7cfWiBQ37DwPloM1PhIoUK4/O60V5KbM4k5Cg== X-Received: by 2002:a37:6841:: with SMTP id d62mr8129473qkc.365.1583420156287; Thu, 05 Mar 2020 06:55:56 -0800 (PST) Received: from localhost ([2620:10d:c091:480::1:e7c7]) by smtp.gmail.com with ESMTPSA id g22sm1058992qtp.8.2020.03.05.06.55.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Mar 2020 06:55:55 -0800 (PST) Date: Thu, 5 Mar 2020 09:55:54 -0500 From: Tejun Heo To: Benjamin Berg Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, Johannes Weiner Subject: Re: Memory reclaim protection and cgroup nesting (desktop use) Message-ID: <20200305145554.GA5897@mtj.thefacebook.com> References: <20200304163044.GF189690@mtj.thefacebook.com> <4d3e00457bba40b25f3ac4fd376ba7306ffc4e68.camel@sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4d3e00457bba40b25f3ac4fd376ba7306ffc4e68.camel@sipsolutions.net> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hello, On Thu, Mar 05, 2020 at 02:13:58PM +0100, Benjamin Berg wrote: > A major discussion point seemed to be that cgroups should be grouped by > their resource management needs rather than a logical hierarchy. I > think that the resource management needs actually map well enough to > the logical hierarchy in our case. The hierarchy looks like: Yeah, the two layouts share a lot of commonalities in most cases. It's not like we usually wanna distribute resources completely unrelated to how the system is composed logically. > root > / \ > system.slice user.slice > / | | \ > cron journal user-1000.slice user-1001.slice > | \ > user@1000.service [SAME] > | | > apps.slice session.slice > | | > unprotected protected > ... > I think this actually makes sense. Both from an hierarchical point of > view and also for configuring resources. In particular the user-.slice > layer is important, because this grouping allows us to dynamically > adjust resource management. The obvious thing we can do there is to > prioritise the currently active user while also lowering resource > allocations for inactive users (e.g. graphical greeter still running in > the background). Changing memory limits dynamically can lead to pretty abrupt system behaviors depending on how big the swing is but memory.low and io/cpu weights should behave fine. > Note, that from my point of view the scenario that most concerns me is > a resource competition between session.slice and its siblings. This > makes the hierarchy above even less important; we just need to give the > user enough control to do resource allocations within their own > subtree. > > So, it seems to me that the suggested mount option should work well in > our scenario. Sounds great. In our experience, what would help quite a lot is using per-application cgroups more (e.g. containing each application as user services) so that one misbehaving command can't overwhelm the session and eventually when oomd has to kick in, it can identify and kill only the culprit application rather than the whole session. Thanks. -- tejun