linux-kernel - Re: [PATCH V5] x86/mm: Tracking linear mapping split events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <33B5B608-4D74-4221-AB0F-AEEBA170AF84@nvidia.com>
Date:   Thu, 28 Jan 2021 11:56:05 -0500
From:   Zi Yan <ziy@...dia.com>
To:     Dave Hansen <dave.hansen@...el.com>
CC:     Saravanan D <saravanand@...com>,
        Xing Zhengjun <zhengjun.xing@...ux.intel.com>,
        <x86@...nel.org>, <dave.hansen@...ux.intel.com>, <luto@...nel.org>,
        <peterz@...radead.org>, <corbet@....net>, <willy@...radead.org>,
        <linux-kernel@...r.kernel.org>, <kernel-team@...com>,
        <linux-doc@...r.kernel.org>, <linux-mm@...ck.org>,
        <songliubraving@...com>
Subject: Re: [PATCH V5] x86/mm: Tracking linear mapping split events

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

> On 1/28/21 8:33 AM, Zi Yan wrote:
>>> 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

Download attachment "signature.asc" of type "application/pgp-signature" (855 bytes)