From: Rik van Riel <riel@redhat.com>
To: Alexey Dobriyan <adobriyan@gmail.com>, linux-mm <linux-mm@kvack.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Maybe move ->anon_vma_chain ?
Date: Thu, 18 Aug 2016 10:45:41 -0400 [thread overview]
Message-ID: <1471531541.2581.16.camel@redhat.com> (raw)
In-Reply-To: <CACVxJT8xH5MLtbqMcNFScNx6chOvQ69OHan8coACeUAVkGkS=g@mail.gmail.com>
On Thu, 2016-08-18 at 17:39 +0300, Alexey Dobriyan wrote:
> FYI,
>
> on x86_64, ->anon_vma_chain has offset 120 inside the structure
> which means that:
> * on CONFIG_NUMA=n CONFIG_USERFAULTFD=n kernels
> every 4-th VMA has this list head spanning 2 cachelines and,
>
> * on CONFIG_NUMA=y CONFIG_USERFAULTFD=y kernels
> _every_ VMA has this peculiar property.
It may make sense to move vm_pgoff into the first
cache line, since that is likely to be used in
conjunction with the rb tree, in rb tree walks.
> Now I don't know good benchmark for anon vmas,
> but maybe you do.
I am not sure what we would use to benchmark this.
> struct vm_area_struct {
> vm_start;A A A A A A A A A A A A A /*A A A A A 0A A A A A 8 */
> vm_end;A A A A A A A A A A A A A A A /*A A A A A 8A A A A A 8 */
> vm_next;A A A A A A A A A A A A A A /*A A A A 16A A A A A 8 */
> vm_prev;A A A A A A A A A A A A A A /*A A A A 24A A A A A 8 */
> vm_rb;A A A A A A A A A A A A A A A A /*A A A A 32A A A A 24 */
> rb_subtree_gap;A A A A A A A /*A A A A 56A A A A A 8 */
> A A A A A A A A /* --- cacheline 1 boundary (64 bytes) --- */
> vm_mm;A A A A A A A A A A A A A A A A /*A A A A 64A A A A A 8 */
> vm_page_prot;A A A A A A A A A /*A A A A 72A A A A A 8 */
> vm_flags;A A A A A A A A A A A A A /*A A A A 80A A A A A 8 */
>
> rb;A A A A A A A A A A A A A A A A A A A /*A A A A 88A A A A 24 */
> rb_subtree_last;A A A A A A /*A A A 112A A A A A 8 */
> A A A A A A A A A A A A A A A A A A A A A A /*A A A A 88A A A A 32 */
>
>
> ===>A A A struct list_head anon_vma_chain; /*A A A 120A A A A 16 */
> A A A A A A A A /* --- cacheline 2 boundary (128 bytes) was 8 bytes ago ---
> */
>
>
> anon_vma;A A A A A A A A A A A A A /*A A A 136A A A A A 8 */
> structA A * vm_ops;A A A A A /*A A A 144A A A A A 8 */
> vm_pgoff;A A A A A A A A A A A A A /*A A A 152A A A A A 8 */
> vm_file;A A A A A A A A A A A A A A /*A A A 160A A A A A 8 */
> vm_private_data;A A A A A A /*A A A 168A A A A A 8 */
> vm_userfaultfd_ctx;A A A /*A A A 176A A A A A 0 */
>
> A A A A A A A A /* size: 176, cachelines: 3, members: 17 */
> A A A A A A A A /* last cacheline: 48 bytes */
> };
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2016-08-18 14:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-18 14:39 Maybe move ->anon_vma_chain ? Alexey Dobriyan
2016-08-18 14:45 ` Rik van Riel [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=1471531541.2581.16.camel@redhat.com \
--to=riel@redhat.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.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.