lkml.org 
[lkml]   [2023]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 14/19] mm: Introduce a cgroup for pinned memory
    On Mon, Feb 6, 2023 at 1:14 PM Tejun Heo <tj@kernel.org> wrote:
    >
    > On Mon, Feb 06, 2023 at 06:47:51PM +1100, Alistair Popple wrote:
    > > If too much memory in a system is pinned or locked it can lead to
    > > problems such as performance degradation or in the worst case
    > > out-of-memory errors as such memory cannot be moved or paged out.
    > >
    > > In order to prevent users without CAP_IPC_LOCK from causing these
    > > issues the amount of memory that can be pinned is typically limited by
    > > RLIMIT_MEMLOCK. However this is inflexible as limits can't be shared
    > > between tasks and the enforcement of these limits is inconsistent
    > > between in-kernel users of pinned memory such as mlock() and device
    > > drivers which may also pin pages with pin_user_pages().
    > >
    > > To allow for a single limit to be set introduce a cgroup controller
    > > which can be used to limit the number of pages being pinned by all
    > > tasks in the cgroup.
    >
    > As I wrote before, I think this might fit better as a part of memcg than as
    > its own controller.

    I guess it boils down to which we want:
    (a) Limit the amount of memory processes in a cgroup can be pinned/locked.
    (b) Limit the amount of memory charged to a cgroup that can be pinned/locked.

    The proposal is doing (a), I suppose if this was part of memcg it
    would be (b), right?

    I am not saying it should be one or the other, I am just making sure
    my understanding is clear.

    >
    > Thanks.
    >
    > --
    > tejun

    \
     
     \ /
      Last update: 2023-03-27 00:11    [W:2.865 / U:0.128 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site