lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 11 Apr 2019 10:02:16 -0400
From:   Waiman Long <>
To:     Michal Hocko <>
Cc:     Tejun Heo <>, Li Zefan <>,
        Johannes Weiner <>,
        Jonathan Corbet <>,
        Vladimir Davydov <>,,,,,
        Andrew Morton <>,
        Roman Gushchin <>,
        Shakeel Butt <>,
        Kirill Tkhai <>,
        Aaron Lu <>
Subject: Re: [RFC PATCH 0/2] mm/memcontrol: Finer-grained memory control

On 04/10/2019 03:54 PM, Michal Hocko wrote:
> On Wed 10-04-19 15:13:19, Waiman Long wrote:
>> The current control mechanism for memory cgroup v2 lumps all the memory
>> together irrespective of the type of memory objects. However, there
>> are cases where users may have more concern about one type of memory
>> usage than the others.
>> We have customer request to limit memory consumption on anonymous memory
>> only as they said the feature was available in other OSes like Solaris.
> Please be more specific about a usecase.

>From that customer's point of view, page cache is more like common goods
that can typically be shared by a number of different groups. Depending
on which groups touch the pages first, it is possible that most of those
pages can be disproportionately attributed to one group than the others.
Anonymous memory, on the other hand, are not shared and so can more
correctly represent the memory footprint of an application. Of course,
there are certainly cases where an application can have large private
files that can consume a lot of cache pages. These are probably not the
case for the applications used by that customer.

>> To allow finer-grained control of memory, this patchset 2 new control
>> knobs for memory controller:
>>  - memory.subset.list for specifying the type of memory to be under control.
>>  - memory.subset.high for the high limit of memory consumption of that
>>    memory type.
> Please be more specific about the semantic.
> I am really skeptical about this feature to be honest, though.

Please see patch 1 which has a more detailed description. This is just
an overview for the cover letter.

>> For simplicity, the limit is not hierarchical and applies to only tasks
>> in the local memory cgroup.
> This is a no-go to begin with.

The reason for doing that is to introduce as little overhead as
possible. We can certainly make it hierarchical, but it will complicate
the code and increase runtime overhead. Another alternative is to limit
this feature to only leaf memory cgroups. That should be enough to cover
what the customer is asking for and leave room for future hierarchical
extension, if needed.


Powered by blists - more mailing lists