On Fri, Feb 07, 2025 at 04:10:47PM +0800, Huang, Ying wrote: > SeongJae Park <sj@xxxxxxxxxx> writes: > > > > I agree the fairness is a thing that we need to aware of. But IMHO, it is > > something that the async approach can further be advanced for, not a strict > > blocker for now. > > Personally, I have no objection to async operations in general. > However, we may need to find some way to control these async operations > instead of adding more and more background kthreads blindly. How to > charge and constrain the resources used by these async operations is > important too. For example, some users may want to bind some async > operations on some CPUs. > > IMHO, we should think about the requirements and possible solutions > instead of ignoring the issues. > It also concerns me that most every proposal on async promotion ignores the promotion-node selection problem as if it's a secondary issue. Async systems fundamentally lack accessor-locality information unless it is recorded - and recording this information is expensive and/or heuristically imprecise for memory shared across tasks (two threads in the same process schedule across sockets). If we can't agree on a solution to this problem, it undercuts many of these RFCs which often simply hard-code the target node to "0" because it's too hard or too expensive to consider the multi-socket scenario. ~Gregory
