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
