Received-SPF: pass (google.com: domain of linux-kernel+bounces-33144-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240118120347.61817-1-ioworker0@gmail.com> <ZakqQyL9t2ffNUIf@tiehlicka>
 <CAK1f24k+=Sskotbct+yGxpDKNv=qyXPkww5i2kaqfzwaUVO_GQ@mail.gmail.com>
 <ZapwWuVTIDeI3W8A@tiehlicka> <CAK1f24m9oxciHsAht4-cCWo_NT7x+bkoXUO2HOwgMCr0OnwpcA@mail.gmail.com>
 <Za5yvjZWVyYjgyfh@tiehlicka>
In-Reply-To: <Za5yvjZWVyYjgyfh@tiehlicka>
From: Lance Yang <ioworker0@gmail.com>
Date: Mon, 22 Jan 2024 22:14:11 +0800
Message-ID: <CAK1f24n+pTw=7atKGAbgBh8qKOTBPq-BEV7ZkLcgN3P0n3h3ug@mail.gmail.com>
Subject: Re: [PATCH v2 1/1] mm/madvise: add MADV_F_COLLAPSE_LIGHT to process_madvise()
To: Michal Hocko <mhocko@suse.com>
Cc: akpm@linux-foundation.org, zokeefe@google.com, 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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 22, 2024 at 9:50=E2=80=AFPM Michal Hocko <mhocko@suse.com> wrot=
e:
>
> 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 wel=
l
> > 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 maintai=
n,
providing userspace with the certainty that requests won=E2=80=99t be block=
ed.

Thanks,
Lance

>
> --
> Michal Hocko
> SUSE Labs