[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87tuha7105.fsf@disp2133>
Date: Thu, 21 Oct 2021 12:15:22 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Pratik Sampat <psampat@...ux.ibm.com>
Cc: Tejun Heo <tj@...nel.org>,
Christian Brauner <christian.brauner@...ntu.com>,
bristot@...hat.com, christian@...uner.io, lizefan.x@...edance.com,
hannes@...xchg.org, mingo@...nel.org, juri.lelli@...hat.com,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
cgroups@...r.kernel.org, containers@...ts.linux.dev,
containers@...ts.linux-foundation.org, pratik.r.sampat@...il.com,
Alexey Gladkov <legion@...nel.org>
Subject: Re: [RFC 0/5] kernel: Introduce CPU Namespace
Pratik Sampat <psampat@...ux.ibm.com> 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
Powered by blists - more mailing lists