Michal Hocko <mhocko@xxxxxxxx> 于2021年8月30日周一 下午9:49写道： > > On Sun 22-08-21 17:46:08, yong w wrote: > > > All those reasons should be a part of the changelog. > > >.... > > > I am not sure these are sufficient justifications but that is something > > > to discuss. And hence it should be a part of the changelog. > > > > > OK, These reasons will be added to the patch notesin later versions. > > > > > > 3. In the case where the user does not need vmpressure, vmpressure > > > > calculation is additional overhead. > > > > > > You should quantify that and argue why that overhead cannot be further > > > reduced without config/boot time knobs. > > > > > The test results of the previously used PFT tool may not be obvious. > > Is there a better way to quantify it? > > This is a question for you to answer I am afraid. You want to add a > configuration option and (as explained) that is not free of cost from > the maintenance POV. There must a very good reason to do that. Sorry for the late reply.The previous email mentions some reasons. and several tools were used to test, but the data did not meet the expectations. I'll try other test methods later. > > > > In some special scenes with tight memory, vmpressure will be executed > > > > frequently.we use "likely" and "inline" > > > > to improve the performance of the kernel, why not reduce some > > > > unnecessary calculations? > > > > > > I am all for improving the code. Is it possible to do it by other means? > > > E.g. reduce a potential overhead when there no events registered? > > Yes, the method you mentioned may be feasible, but it does not conflict > > with this patch. > > It is not in conflict but runtime overhead reduction without more burden > on the configurability is usually a preferred approach. I agree with you.I had an idea that we use global variables to identify whether there is event registration,however, global variables need to be protected with locks. I feel that there is little room for optimization in the code. Thanks.
