[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y+Fttp1ozejoSQzl@slm.duckdns.org>
Date: Mon, 6 Feb 2023 11:14:30 -1000
From: Tejun Heo <tj@...nel.org>
To: Alistair Popple <apopple@...dia.com>
Cc: linux-mm@...ck.org, cgroups@...r.kernel.org,
linux-kernel@...r.kernel.org, jgg@...dia.com, jhubbard@...dia.com,
tjmercier@...gle.com, hannes@...xchg.org, surenb@...gle.com,
mkoutny@...e.com, daniel@...ll.ch,
"Daniel P . Berrange" <berrange@...hat.com>,
Alex Williamson <alex.williamson@...hat.com>,
Zefan Li <lizefan.x@...edance.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 14/19] mm: Introduce a cgroup for pinned memory
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.
Thanks.
--
tejun
Powered by blists - more mailing lists