On Fri 15-01-21 15:23:07, Xing Zhengjun wrote: > Hi, > > There is currently a bit of a debate about the kernel direct map. Does using > 2M/1G pages aggressively for the kernel direct map help performance? Or, is > it an old optimization which is not as helpful on modern CPUs as it was in > the old days? What is the penalty of a kernel feature that heavily demotes > this mapping from larger to smaller pages? We did a set of runs with 1G and > 2M pages enabled /disabled and saw the changes. > > [Conclusions] > > Assuming that this was a good representative set of workloads and that the > data are good, for server usage, we conclude that the existing aggressive > use of 1G mappings is a good choice since it represents the best in a > plurality of the workloads. However, in a *majority* of cases, another > mapping size (2M or 4k) potentially offers a performance improvement. This > leads us to conclude that although 1G mappings are a good default choice, > there is no compelling evidence that it must be the only choice, or that > folks deriving benefits (like hardening) from smaller mapping sizes should > avoid the smaller mapping sizes. Thanks for conducting these tests! This is definitely useful and quite honestly I would have expected a much more noticeable differences. Please note that I am not really deep into benchmarking but one thing that popped in my mind was whethere these (micro)benchmarks are really representative workloads. Some of them tend to be rather narrow in executed code paths or data structures used AFAIU. Is it possible they simply didn't generate sufficient TLB pressure? Have you tried to look closer on profiles of respective configurations where the overhead comes from? -- Michal Hocko SUSE Labs
