From: "Zi Yan" <ziy@nvidia.com>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"Tejun Heo" <tj@kernel.org>,
"FUJITA Tomonori" <fujita.tomonori@lab.ntt.co.jp>,
"Douglas Gilbert" <dougg@torque.net>,
"Chris Wilson" <chris@chris-wilson.co.uk>,
"Christoph Hellwig" <hch@lst.de>
Subject: Re: [PATCH] mm: Optimise nth_page for contiguous memmap
Date: Wed, 14 Apr 2021 11:27:25 -0400 [thread overview]
Message-ID: <CF4348D5-9BDD-4A93-891F-D81FD15ED174@nvidia.com> (raw)
In-Reply-To: <20210413194625.1472345-1-willy@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 2360 bytes --]
On 13 Apr 2021, at 15:46, Matthew Wilcox (Oracle) wrote:
> If the memmap is virtually contiguous (either because we're using
> a virtually mapped memmap or because we don't support a discontig
> memmap at all), then we can implement nth_page() by simple addition.
> Contrary to popular belief, the compiler is not able to optimise this
> itself for a vmemmap configuration. This reduces one example user (sg.c)
> by four instructions:
>
> struct page *page = nth_page(rsv_schp->pages[k], offset >> PAGE_SHIFT);
>
> before:
> 49 8b 45 70 mov 0x70(%r13),%rax
> 48 63 c9 movslq %ecx,%rcx
> 48 c1 eb 0c shr $0xc,%rbx
> 48 8b 04 c8 mov (%rax,%rcx,8),%rax
> 48 2b 05 00 00 00 00 sub 0x0(%rip),%rax
> R_X86_64_PC32 vmemmap_base-0x4
> 48 c1 f8 06 sar $0x6,%rax
> 48 01 d8 add %rbx,%rax
> 48 c1 e0 06 shl $0x6,%rax
> 48 03 05 00 00 00 00 add 0x0(%rip),%rax
> R_X86_64_PC32 vmemmap_base-0x4
>
> after:
> 49 8b 45 70 mov 0x70(%r13),%rax
> 48 63 c9 movslq %ecx,%rcx
> 48 c1 eb 0c shr $0xc,%rbx
> 48 c1 e3 06 shl $0x6,%rbx
> 48 03 1c c8 add (%rax,%rcx,8),%rbx
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> ---
> include/linux/mm.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 25b9041f9925..2327f99b121f 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -234,7 +234,11 @@ int overcommit_policy_handler(struct ctl_table *, int, void *, size_t *,
> int __add_to_page_cache_locked(struct page *page, struct address_space *mapping,
> pgoff_t index, gfp_t gfp, void **shadowp);
>
> +#if defined(CONFIG_SPARSEMEM) && !defined(CONFIG_SPARSEMEM_VMEMMAP)
> #define nth_page(page,n) pfn_to_page(page_to_pfn((page)) + (n))
> +#else
> +#define nth_page(page,n) ((page) + (n))
> +#endif
>
> /* to align the pointer to the (next) page boundary */
> #define PAGE_ALIGN(addr) ALIGN(addr, PAGE_SIZE)
> --
> 2.30.2
LGTM. Thanks.
Reviewed-by: Zi Yan <ziy@nvidia.com>
—
Best Regards,
Yan Zi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]
prev parent reply other threads:[~2021-04-14 15:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-13 19:46 [PATCH] mm: Optimise nth_page for contiguous memmap Matthew Wilcox (Oracle)
2021-04-14 15:24 ` David Hildenbrand
2021-04-14 18:51 ` Matthew Wilcox
2021-04-14 18:56 ` David Hildenbrand
2021-04-14 15:27 ` Zi Yan [this message]
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=CF4348D5-9BDD-4A93-891F-D81FD15ED174@nvidia.com \
--to=ziy@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=chris@chris-wilson.co.uk \
--cc=dougg@torque.net \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tj@kernel.org \
--cc=willy@infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.