archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <>
To: "Vlastimil Babka" <>,
	"Łukasz Daniluk" <>,,
Subject: Re: [RESEND PATCH 0/3] mm: Add cache coloring mechanism
Date: Fri, 25 Aug 2017 06:10:49 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 08/25/2017 02:04 AM, Vlastimil Babka wrote:
> On 08/24/2017 06:08 PM, Dave Hansen wrote:
>> On 08/24/2017 05:47 AM, Vlastimil Babka wrote:
>>> 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?
>> The cache in this case is "MCDRAM" which is 16GB in size.  It can be
>> used as normal RAM or a cache.  This patch deals with when "MCDRAM" is
>> in its cache mode.
> Hm, 16GB direct mapped, that means 8k colors for 2MB THP's. Is that
> really practical? Wouldn't such workload use 1GB hugetlbfs pages? Then
> it's still 16 colors to manage, but could be done purely in userspace
> since they should not move in physical memory and userspace can control
> where to map each phase in the virtual layout.

There are lots of options for applications that are written with
specific knowledge of MCDRAM.  The easiest option from the kernel's
perspective is to just turn the caching mode off and treat MCDRAM as
normal RAM (it shows up in a separate NUMA node in that case).

But, one of the reasons for the cache mode in the first place was to
support applications that don't have specific knowledge of MCDRAM.  Or,
even old binaries that were compiled long ago.

In other words, I don't think this is something we can easily punt to

To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to  For more info on Linux MM,
see: .
Don't email: <a href=mailto:""> </a>

      reply	other threads:[~2017-08-25 13:10 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 ` [RESEND PATCH 0/3] mm: Add cache coloring mechanism Vlastimil Babka
2017-08-24 16:08   ` Dave Hansen
2017-08-25  9:04     ` Vlastimil Babka
2017-08-25 13:10       ` Dave Hansen [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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* 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).