On Thu 29-08-24 21:15:50, Zhongkun He wrote: > On Thu, Aug 29, 2024 at 7:51 PM Michal Hocko <mhocko@xxxxxxxx> wrote: [...] > > Is this some artificial workload or something real world? > > > > This is an artificial workload to show the detail of this case more > easily. But we have encountered this problem on our servers. This is always good to mention in the changelog. If you can observe this in real workloads it is good to get numbers from those because artificial workloads tend to overshoot the underlying problem and we can potentially miss the practical contributors to the problem. Seeing this my main question is whether we should focus on swappiness behavior more than adding a very strange and very targetted reclaim mode. After all we have a mapped memory and executables protection in place. So in the end this is more about balance between anon vs. file LRUs. > If the performance of the disk is poor, like HDD, the situation will > become even worse. Doesn't that impact swapin/out as well? Or do you happen to have a faster storage for the swap? > The delay of the task becomes more serious because reading data will > be slower. Hot pages will thrash repeatedly between the memory and > the disk. Doesn't refault stats and IO cost aspect of the reclaim when balancing LRUs dealing with this situation already? Why it doesn't work in your case? Have you tried to investigate that? -- Michal Hocko SUSE Labs
