Re: [External] Re: [RFC PATCH 0/2] Add disable_unmap_file arg to memory.reclaim

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux