All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: hannes@cmpxchg.org, roman.gushchin@linux.dev,
	shakeel.butt@linux.dev, muchun.song@linux.dev,
	akpm@linux-foundation.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH 0/2] memcg: add nomlock to avoid folios beling mlocked in a memcg
Date: Tue, 7 Jan 2025 11:04:49 +0100	[thread overview]
Message-ID: <Z3z8QWI-azLsf1xw@tiehlicka> (raw)
In-Reply-To: <CALOAHbC6QdNbn62ZHRCY-PTNevz+wtxMUWgUnLsLFUc1ZC5+YQ@mail.gmail.com>

On Mon 06-01-25 21:59:07, Yafang Shao wrote:
> On Mon, Jan 6, 2025 at 8:28 PM Michal Hocko <mhocko@suse.com> wrote:
[...]
> > The purpose of mlock syscall is to _guarantee_ memory to be resident
> > (never swapped out). There might be additional constrains to prevent
> > from mlock succeeding - e.g. rlimit or if memcg aims to control amount
> > of the mlocked memory but those failures need to be explicitly
> > communicated via syscall failure.
> 
> Returning an error code like EBUSY to userspace is straightforward
> when attempting to mlock a page that is charged to a different memcg.

EAGAIN is already documented error failure when some pages cannot be
mlocked, but yes this would be acceptable solution. The question is how
to handle mlockall(MCL_FUTURE) resp. mlock(MLOCK_ONFAULT). I didn't give
those much time but I can see some comlications there. Either we fail
those on shared resources which could lead to pre-mature failures or we
need to somehow record lock ownership and enforce it during the fault
(charge).
-- 
Michal Hocko
SUSE Labs


      reply	other threads:[~2025-01-07 10:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-15  7:34 [RFC PATCH 0/2] memcg: add nomlock to avoid folios beling mlocked in a memcg Yafang Shao
2024-12-15  7:34 ` [RFC PATCH 1/2] mm/memcontrol: add a new cgroup file memory.nomlock Yafang Shao
2024-12-15  7:34 ` [RFC PATCH 2/2] mm: Add support for nomlock to avoid folios beling mlocked in a memcg Yafang Shao
2024-12-20 10:23 ` [RFC PATCH 0/2] memcg: add " Michal Hocko
2024-12-20 11:52   ` Yafang Shao
2024-12-21  7:21     ` Michal Hocko
2024-12-22  2:34       ` Yafang Shao
2024-12-25  2:23         ` Yafang Shao
2025-01-06 12:30           ` Michal Hocko
2025-01-06 14:04             ` Yafang Shao
2025-01-07  8:39               ` Michal Hocko
2025-01-07  9:43                 ` Yafang Shao
2025-01-06 12:28         ` Michal Hocko
2025-01-06 13:59           ` Yafang Shao
2025-01-07 10:04             ` Michal Hocko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z3z8QWI-azLsf1xw@tiehlicka \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=laoar.shao@gmail.com \
    --cc=linux-mm@kvack.org \
    --cc=muchun.song@linux.dev \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.