On 28 Jan 2021, at 11:41, Dave Hansen wrote:

On 1/28/21 8:33 AM, Zi Yan wrote:

quoted

quoted

One of the many lasting (as we don't coalesce back) sources for
huge page splits is tracing as the granular page
attribute/permission changes would force the kernel to split code
segments mapped to huge pages to smaller ones thereby increasing
the probability of TLB miss/reload even after tracing has been
stopped.

It is interesting to see this statement saying splitting kernel
direct mappings causes performance loss, when Zhengjun (cc’d) from
Intel recently posted a kernel direct mapping performance report[1]
saying 1GB mappings are good but not much better than 2MB and 4KB
mappings.

No, that's not what the report said.

*Overall*, there is no clear winner between 4k, 2M and 1G.  In other
words, no one page size is best for *ALL* workloads.

There were *ABSOLUTELY* individual workloads in those tests that saw
significant deltas between the direct map sizes.  There are also
real-world workloads that feel the impact here.

Yes, it is what I understand from the report. But this patch says
“
Maintaining huge direct mapped pages greatly reduces TLB miss pressure.
The splintering of huge direct pages into smaller ones does result in
a measurable performance hit caused by frequent TLB miss and reloads.
”,

indicating large mappings (2MB, 1GB) are generally better. It is
different from what the report said, right?

The above text could be improved to make sure readers get both sides
of the story and not get afraid of performance loss after seeing
a lot of direct_map_xxx_splits events.



—
Best Regards,
Yan Zi