Hey Zach, What do you think about the semantic? Thanks, Lance On Mon, Jan 22, 2024 at 10:14 PM Lance Yang <ioworker0@xxxxxxxxx> wrote: > > On Mon, Jan 22, 2024 at 9:50 PM Michal Hocko <mhocko@xxxxxxxx> 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
