Michal Hocko <mhocko@xxxxxxxx> writes: > On Wed 12-07-23 15:45:58, Huang, Ying wrote: >> Michal Hocko <mhocko@xxxxxxxx> writes: >> >> > On Mon 10-07-23 14:53:24, Huang Ying wrote: >> >> The page allocation performance requirements of different workloads >> >> are usually different. So, we often need to tune PCP (per-CPU >> >> pageset) high to optimize the workload page allocation performance. >> >> Now, we have a system wide sysctl knob (percpu_pagelist_high_fraction) >> >> to tune PCP high by hand. But, it's hard to find out the best value >> >> by hand. And one global configuration may not work best for the >> >> different workloads that run on the same system. One solution to >> >> these issues is to tune PCP high of each CPU automatically. >> >> >> >> This patch adds the framework for PCP high auto-tuning. With it, >> >> pcp->high will be changed automatically by tuning algorithm at >> >> runtime. Its default value (pcp->high_def) is the original PCP high >> >> value calculated based on low watermark pages or >> >> percpu_pagelist_high_fraction sysctl knob. To avoid putting too many >> >> pages in PCP, the original limit of percpu_pagelist_high_fraction >> >> sysctl knob, MIN_PERCPU_PAGELIST_HIGH_FRACTION, is used to calculate >> >> the max PCP high value (pcp->high_max). >> > >> > It would have been very helpful to describe the basic entry points to >> > the auto-tuning. AFAICS the central place of the tuning is tune_pcp_high >> > which is called from the freeing path. Why? Is this really a good place >> > considering this is a hot path? What about the allocation path? Isn't >> > that a good spot to watch for the allocation demand? >> >> Yes. The main entry point to the auto-tuning is tune_pcp_high(). Which >> is called from the freeing path because pcp->high is only used by page >> freeing. It's possible to call it in allocation path instead. The >> drawback is that the pcp->high may be updated a little later in some >> situations. For example, if there are many page freeing but no page >> allocation for quite long time. But I don't think this is a serious >> problem. > > I consider it a serious flaw in the framework as it cannot cope with the > transition of the allocation pattern (e.g. increasing the allocation > pressure). Sorry, my previous words are misleading. What I really wanted to say is that the problem may be just theoretical. Anyway, I will try to avoid this problem in the future version. >> > Also this framework seems to be enabled by default. Is this really >> > desirable? What about workloads tuning the pcp batch size manually? >> > Shouldn't they override any auto-tuning? >> >> In the current implementation, the pcp->high will be tuned between >> original pcp high (default or tuned manually) and the max pcp high (via >> MIN_PERCPU_PAGELIST_HIGH_FRACTION). So the high value tuned manually is >> respected at some degree. >> >> So you think that it's better to disable auto-tuning if PCP high is >> tuned manually? > > Yes, I think this is a much safer option. For two reasons 1) it is less > surprising to setups which know what they are doing by configuring the > batching and 2) the auto-tuning needs a way to get disabled in case > there are pathological patterns in behavior. OK. Best Regards, Huang, Ying
