linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: "Łukasz Daniluk" <lukasz.daniluk@intel.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: dave.hansen@intel.com, lukasz.anaczkowski@intel.com
Subject: Re: [RESEND PATCH 0/3] mm: Add cache coloring mechanism
Date: Thu, 24 Aug 2017 14:47:53 +0200	[thread overview]
Message-ID: <f95eacd5-0a91-24a0-7722-b63f3c196552@suse.cz> (raw)
In-Reply-To: <20170823100205.17311-1-lukasz.daniluk@intel.com>

On 08/23/2017 12:02 PM, A?ukasz Daniluk wrote:
> Patches resend with Linux Kernel Mailing List added correctly this time.
> 
> This patch series adds cache coloring mechanism that works along buddy
> allocator. The solution is opt-in, disabled by default minimally
> interferes with default allocation paths due to added if statements.
> 
> Why would such patches be needed? Big caches with low associativity
> (direct mapped caches, 2-way associative) will benefit from the solution
> the most - it allows for near constant performance through the lifetime
> of a system, despite the allocations and deallocations happening and
> reordering buddy lists.

So the obvious question, what about THPs? Their size should be enough to
contain all the colors with current caches, no? Even on KNL I didn't
find more than "32x 1 MB 16-way L2 caches". This is in addition to the
improved TLB performance, which you want to get as well for such workloads?

> On KNL system, the STREAM benchmark with problem size resulting in its
> internal arrays being of 16GB size will yield bandwidth performance of
> 336GB/s after fresh boot. With cache coloring patches applied and
> enabled, this performance stays near constant (most 1.5% drop observed),
> despite running benchmark multiple times with varying sizes over course
> of days.  Without these patches however, the bandwidth when using such
> allocations drops to 117GB/s - over 65% of irrecoverable performance
> penalty. Workloads that exceed set cache size suffer from decreased
> randomization of allocations with cache coloring enabled, but effect of
> cache usage disappears roughly at the same allocation size.

So was the test with THP's enabled or disabled? And what was the cache
configuration and the values of cache_color_size and
cache_color_min_order parameters?

I'm also confused about the "cache_color_min_order=" parameter. If this
wants to benefit non-THP userspace, then you would need to set it to 0,
right? Or does this mean that indeed you expect THP to not contain all
the colors, so you'd set it to the THP order (9)?

> Solution is divided into three patches. First patch is a preparatory one
> that provides interface for retrieving (information about) free lists
> contained by particular free_area structure.  Second one (parallel
> structure keeping separate list_heads for each cache color in a given
> context) shows general solution overview and is working as it is.
> However, it has serious performance implications with bigger caches due
> to linear search for next color to be used during allocations. Third
> patch (sorting list_heads using RB trees) aims to improve solution's
> performance by replacing linear search for next color with searching in
> RB tree. While improving computational performance, it imposes increased
> memory cost of the solution.
> 
> 
> A?ukasz Daniluk (3):
>   mm: move free_list selection to dedicated functions
>   mm: Add page colored allocation path
>   mm: Add helper rbtree to search for next cache color
> 
>  Documentation/admin-guide/kernel-parameters.txt |   8 +
>  include/linux/mmzone.h                          |  12 +-
>  mm/compaction.c                                 |   4 +-
>  mm/page_alloc.c                                 | 381 ++++++++++++++++++++++--
>  mm/vmstat.c                                     |  10 +-
>  5 files changed, 383 insertions(+), 32 deletions(-)
> 

--
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>

  parent reply	other threads:[~2017-08-24 12:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-23 10:02 [RESEND PATCH 0/3] mm: Add cache coloring mechanism Łukasz Daniluk
2017-08-23 10:02 ` [RESEND PATCH 1/3] mm: move free_list selection to dedicated functions Łukasz Daniluk
2017-08-23 10:02 ` [RESEND PATCH 2/3] mm: Add page colored allocation path Łukasz Daniluk
2017-08-23 13:51   ` Dave Hansen
2017-08-23 10:02 ` [RESEND PATCH 3/3] mm: Add helper rbtree to search for next cache color Łukasz Daniluk
2017-08-24 12:47 ` Vlastimil Babka [this message]
2017-08-24 16:08   ` [RESEND PATCH 0/3] mm: Add cache coloring mechanism Dave Hansen
2017-08-25  9:04     ` Vlastimil Babka
2017-08-25 13:10       ` 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=f95eacd5-0a91-24a0-7722-b63f3c196552@suse.cz \
    --to=vbabka@suse.cz \
    --cc=dave.hansen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lukasz.anaczkowski@intel.com \
    --cc=lukasz.daniluk@intel.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;
as well as URLs for NNTP newsgroup(s).