How about MADV_F_COLLAPSE_NODEFRAG? On Sat, Jan 27, 2024 at 7:27 AM Zach O'Keefe <zokeefe@xxxxxxxxxx> wrote: > > On Mon, Jan 22, 2024 at 6:35 AM Lance Yang <ioworker0@xxxxxxxxx> 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@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
