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). > > 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. -- Michal Hocko SUSE Labs
