Re: [PATCH] [RESEND] vmscan.c: add a sysctl entry for controlling memory reclaim IO congestion_wait length

On Thu 19-09-19 09:32:48, Lin Feng wrote: > > > On 9/18/19 20:27, Michal Hocko wrote: > > Please do not post a new version with a minor compile fixes until there > > is a general agreement on the approach. Willy had comments which really > > need to be resolved first. > > Sorry, but thanks for

Re: [PATCH] [RESEND] vmscan.c: add a sysctl entry for controlling memory reclaim IO congestion_wait length

On 9/18/19 20:27, Michal Hocko wrote: Please do not post a new version with a minor compile fixes until there is a general agreement on the approach. Willy had comments which really need to be resolved first. Sorry, but thanks for pointing out. Also does this [...] Reported-by: kbuild

Re: [PATCH] [RESEND] vmscan.c: add a sysctl entry for controlling memory reclaim IO congestion_wait length

Please do not post a new version with a minor compile fixes until there is a general agreement on the approach. Willy had comments which really need to be resolved first. And I do agree with him. Having an explicit tunable seems just wrong. Also does this [...] > Reported-by: kbuild test robot

[PATCH] [RESEND] vmscan.c: add a sysctl entry for controlling memory reclaim IO congestion_wait length

This sysctl is named as mm_reclaim_congestion_wait_jiffies, default to HZ/10 as unchanged to old codes. It is in jiffies unit and can be set in range between [1, 100], so refers to CONFIG_HZ before tuning. In a high-end production environment(all high iops ssds) we found that CPU iowait spikes a