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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F34C5C433FE for ; Thu, 21 Oct 2021 17:15:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D8FEB61A79 for ; Thu, 21 Oct 2021 17:15:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232004AbhJURRv (ORCPT ); Thu, 21 Oct 2021 13:17:51 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:33636 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229567AbhJURRt (ORCPT ); Thu, 21 Oct 2021 13:17:49 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]:37160) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mdbf9-000AMa-Iy; Thu, 21 Oct 2021 11:15:31 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:57708 helo=email.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mdbf8-004CFX-64; Thu, 21 Oct 2021 11:15:31 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Pratik Sampat Cc: Tejun Heo , Christian Brauner , bristot@redhat.com, christian@brauner.io, lizefan.x@bytedance.com, hannes@cmpxchg.org, mingo@kernel.org, juri.lelli@redhat.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, cgroups@vger.kernel.org, containers@lists.linux.dev, containers@lists.linux-foundation.org, pratik.r.sampat@gmail.com, Alexey Gladkov References: <20211009151243.8825-1-psampat@linux.ibm.com> <20211011101124.d5mm7skqfhe5g35h@wittgenstein> <77854748-081f-46c7-df51-357ca78b83b3@linux.ibm.com> Date: Thu, 21 Oct 2021 12:15:22 -0500 In-Reply-To: <77854748-081f-46c7-df51-357ca78b83b3@linux.ibm.com> (Pratik Sampat's message of "Wed, 20 Oct 2021 16:14:25 +0530") Message-ID: <87tuha7105.fsf@disp2133> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1mdbf8-004CFX-64;;;mid=<87tuha7105.fsf@disp2133>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+k81XzcFL3nUOkF05szMGteN8T3vDwHqg= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [RFC 0/5] kernel: Introduce CPU Namespace X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Pratik Sampat writes: > On 18/10/21 9:59 pm, Tejun Heo wrote: >> (cc'ing Johannes for memory sizing part) >> >> For memory, it's even trickier because in a lot of cases it's impossible to >> tell how much memory is actually available without trying to use them as >> active workingset can only be learned by trying to reclaim memory. > > Restrictions for memory are even more complicated to model as you have > pointed out as well. For memory sizing we currently have MemAvailable in /proc/meminfo which makes a global guess at that. We still need roughly that same approximation from an applications perspective that takes cgroups into account. There was another conversation not too long ago and it was tenatively agreed that it could make sense to provide such a number. However it was very much requested that an application that would actually use that number be found so it would be possible to tell what makes a difference in practice rather than what makes a difference in theory. Eric