From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Michal Hocko <mhocko@suse.com>,
Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
kirill@shutemov.name, kirill.shutemov@linux.intel.com,
vbabka@suse.cz, will.deacon@arm.com, dave.hansen@intel.com
Subject: Re: [RFC 0/4] mm: Introduce lazy exec permission setting on a page
Date: Thu, 14 Feb 2019 11:34:09 +0530 [thread overview]
Message-ID: <0b6457d0-eed1-54e4-789b-d62881bea013@arm.com> (raw)
In-Reply-To: <20190213153819.GS4525@dhcp22.suse.cz>
On 02/13/2019 09:08 PM, Michal Hocko wrote:
> On Wed 13-02-19 11:21:36, Catalin Marinas wrote:
>> On Wed, Feb 13, 2019 at 01:36:27PM +0530, Anshuman Khandual wrote:
>>> Setting an exec permission on a page normally triggers I-cache invalidation
>>> which might be expensive. I-cache invalidation is not mandatory on a given
>>> page if there is no immediate exec access on it. Non-fault modification of
>>> user page table from generic memory paths like migration can be improved if
>>> setting of the exec permission on the page can be deferred till actual use.
>>> There was a performance report [1] which highlighted the problem.
>> [...]
>>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-December/620357.html
>>
>> FTR, this performance regression has been addressed by commit
>> 132fdc379eb1 ("arm64: Do not issue IPIs for user executable ptes"). That
>> said, I still think this patch series is valuable for further optimising
>> the page migration path on arm64 (and can be extended to other
>> architectures that currently require I/D cache maintenance for
>> executable pages).
>
> Are there any numbers to show the optimization impact?
This series transfers execution cost linearly with nr_pages from migration path
to subsequent exec access path for normal, THP and HugeTLB pages. The experiment
is on mainline kernel (1f947a7a011fcceb14cb912f548) along with some patches for
HugeTLB and THP migration enablement on arm64 platform.
A. [Normal Pages]
nr_pages migration1 migration2 execfault1 execfault2
1000 7.000000 3.000000 24.000000 31.000000
5000 38.000000 18.000000 127.000000 153.000000
10000 80.000000 40.000000 289.000000 343.000000
15000 120.000000 60.000000 435.000000 514.000000
19900 159.000000 79.000000 576.000000 681.000000
B. [THP Pages]
nr_pages migration1 migration2 execfault1 execfault2
10 22.000000 3.000000 131.000000 146.000000
30 72.000000 15.000000 443.000000 503.000000
50 121.000000 24.000000 739.000000 837.000000
100 242.000000 49.000000 1485.000000 1673.000000
199 473.000000 98.000000 2685.000000 3327.000000
C. [HugeTLB Pages]
nr_pages migration1 migration2 execfault1 execfault2
10 97.000000 79.000000 125.000000 144.000000
30 292.000000 235.000000 408.000000 463.000000
50 487.000000 392.000000 674.000000 777.000000
100 995.000000 802.000000 1480.000000 1671.000000
130 1300.000000 1048.000000 1925.000000 2172.000000
NOTE:
migration1: Execution time (ms) for migrating nr_pages without patches
migration2: Execution time (ms) for migrating nr_pages with patches
execfault1: Execution time (ms) for executing nr_pages without patches
execfault2: Execution time (ms) for executing nr_pages with patches
next prev parent reply other threads:[~2019-02-14 6:04 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-13 8:06 Anshuman Khandual
2019-02-13 8:06 ` [RFC 1/4] " Anshuman Khandual
2019-02-13 13:17 ` Matthew Wilcox
2019-02-13 13:53 ` Anshuman Khandual
2019-02-14 9:06 ` Mike Rapoport
2019-02-15 8:11 ` Anshuman Khandual
2019-02-15 9:49 ` Catalin Marinas
2019-02-13 8:06 ` [RFC 2/4] arm64/mm: Identify user level instruction faults Anshuman Khandual
2019-02-13 8:06 ` [RFC 3/4] arm64/mm: Allow non-exec to exec transition in ptep_set_access_flags() Anshuman Khandual
2019-02-13 8:06 ` [RFC 4/4] arm64/mm: Enable ARCH_SUPPORTS_LAZY_EXEC Anshuman Khandual
2019-02-13 11:21 ` [RFC 0/4] mm: Introduce lazy exec permission setting on a page Catalin Marinas
2019-02-13 15:38 ` Michal Hocko
2019-02-14 6:04 ` Anshuman Khandual [this message]
2019-02-14 8:38 ` Michal Hocko
2019-02-14 10:19 ` Catalin Marinas
2019-02-14 12:28 ` Michal Hocko
2019-02-15 8:45 ` Anshuman Khandual
2019-02-15 9:27 ` Michal Hocko
2019-02-18 3:07 ` Anshuman Khandual
2019-02-14 15:38 ` Dave Hansen
2019-02-18 3:19 ` Anshuman Khandual
2019-02-13 15:44 ` Dave Hansen
2019-02-14 4:12 ` Anshuman Khandual
2019-02-14 16:55 ` Dave Hansen
2019-02-18 8:31 ` Anshuman Khandual
2019-02-18 9:04 ` Catalin Marinas
2019-02-18 9:16 ` Anshuman Khandual
2019-02-18 18:20 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0b6457d0-eed1-54e4-789b-d62881bea013@arm.com \
--to=anshuman.khandual@arm.com \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=vbabka@suse.cz \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox