From: Lance Yang <ioworker0@gmail.com>
To: "Zach O'Keefe" <zokeefe@google.com>
Cc: Michal Hocko <mhocko@suse.com>,
akpm@linux-foundation.org, david@redhat.com,
songmuchun@bytedance.com, shy828301@gmail.com,
peterx@redhat.com, mknyszek@google.com, minchan@kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org
Subject: Re: [PATCH v2 1/1] mm/madvise: add MADV_F_COLLAPSE_LIGHT to process_madvise()
Date: Sat, 27 Jan 2024 16:06:39 +0800 [thread overview]
Message-ID: <CAK1f24=tfxgUpdPix1n-4fre70UVFhLbzEqEj7SthUMRJtT59g@mail.gmail.com> (raw)
In-Reply-To: <CAAa6QmRLfwhyh66bVVakp__Rkzpkt3zq2kAe9F-KN5sdFdqLAg@mail.gmail.com>
How about MADV_F_COLLAPSE_NODEFRAG?
On Sat, Jan 27, 2024 at 7:27 AM Zach O'Keefe <zokeefe@google.com> wrote:
>
> On Mon, Jan 22, 2024 at 6:35 AM Lance Yang <ioworker0@gmail.com> wrote:
> >
> > Hey Zach,
> >
> > What do you think about the semantic?
>
> Hey Lance,
>
> Sorry for the late reply.
>
> I can see both sides of the argument; though I would argue that
> "non-blocking" is equally as vague in this context. E.g. we'll "block" on
> acquiring a number of different locks along the collapse path.
>
> If you really want to talk about not entering direct reclaim /
> compaction, then keeping with the sys/kernel/vm/thp notion of "defrag"
> would be better, IMO. I don't feel that strongly about it though.
>
> But I see you've provided some more use cases in another mail, so let
> me pick up my thoughts over there.
>
> Best,
> Zach
>
>
>
> > Thanks,
> > Lance
> >
> > On Mon, Jan 22, 2024 at 10:14 PM Lance Yang <ioworker0@gmail.com> wrote:
> > >
> > > On Mon, Jan 22, 2024 at 9:50 PM Michal Hocko <mhocko@suse.com> wrote:
> > > >
> > > > On Sat 20-01-24 10:09:32, Lance Yang wrote:
> > > > [...]
> > > > > Hey Michal,
> > > > >
> > > > > Thanks for your suggestion!
> > > > >
> > > > > It seems that the implementation should try but not too hard aligns well
> > > > > with my desired behavior.
> > > >
> > > > The problem I have with this semantic is that it is really hard to
> > > > define and then stick with. Our implementation might change over time
> > > > and what somebody considers good ATM might turn int "trying harder than
> > > > I wanted" later on.
> > > >
> > > > > Non-blocking in general is also a great idea.
> > > > > Perhaps in the future, we can add a MADV_F_COLLAPSE_NOBLOCK
> > > > > flag for scenarios where latency is extremely critical.
> > > >
> > > > Non blocking semantic is much easier to define and maintain. The actual
> > > > allocation/compaction implementation might change as well over time but
> > > > the userspace at least knows that the request will not block waiting for
> > > > any required resources.
> > >
> > > I appreciate your insights!
> > >
> > > It makes sense that a non-blocking semantic is easier to define and maintain,
> > > providing userspace with the certainty that requests won’t be blocked.
> > >
> > > Thanks,
> > > Lance
> > >
> > > >
> > > > --
> > > > Michal Hocko
> > > > SUSE Labs
next prev parent reply other threads:[~2024-01-27 8:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240118120347.61817-1-ioworker0@gmail.com>
2024-01-18 13:28 ` [PATCH v2 1/1] mm/madvise: add MADV_F_COLLAPSE_LIGHT to process_madvise() Michal Hocko
[not found] ` <ZakqQyL9t2ffNUIf@tiehlicka>
2024-01-18 13:43 ` Michal Hocko
2024-01-18 14:58 ` Zach O'Keefe
2024-01-18 19:00 ` Yang Shi
2024-01-19 2:37 ` Lance Yang
2024-01-19 1:46 ` Lance Yang
[not found] ` <CAK1f24k+=Sskotbct+yGxpDKNv=qyXPkww5i2kaqfzwaUVO_GQ@mail.gmail.com>
[not found] ` <ZapwWuVTIDeI3W8A@tiehlicka>
[not found] ` <CAK1f24m9oxciHsAht4-cCWo_NT7x+bkoXUO2HOwgMCr0OnwpcA@mail.gmail.com>
[not found] ` <Za5yvjZWVyYjgyfh@tiehlicka>
[not found] ` <CAK1f24n+pTw=7atKGAbgBh8qKOTBPq-BEV7ZkLcgN3P0n3h3ug@mail.gmail.com>
2024-01-22 14:34 ` Lance Yang
2024-01-26 23:26 ` Zach O'Keefe
2024-01-27 8:06 ` Lance Yang [this message]
2024-01-21 3:12 ` Lance Yang
2024-01-26 6:16 ` Lance Yang
2024-01-26 10:15 ` Lance Yang
2024-01-26 12:52 ` Lance Yang
2024-01-26 23:46 ` Zach O'Keefe
2024-01-27 8:03 ` Lance Yang
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='CAK1f24=tfxgUpdPix1n-4fre70UVFhLbzEqEj7SthUMRJtT59g@mail.gmail.com' \
--to=ioworker0@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=mknyszek@google.com \
--cc=peterx@redhat.com \
--cc=shy828301@gmail.com \
--cc=songmuchun@bytedance.com \
--cc=zokeefe@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).