From: "Kani, Toshi" <toshi.kani@hpe.com>
To: "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
"brian.stark@sanmina.com" <brian.stark@sanmina.com>
Subject: Re: Write through caching on NVDIMM
Date: Fri, 20 Apr 2018 21:33:35 +0000 [thread overview]
Message-ID: <1524259971.2693.432.camel@hpe.com> (raw)
In-Reply-To: <CAKccVayU9NW6gWao=w-h3aZaRrCW-=-J7he0hVeWjBA+hjhJ=g@mail.gmail.com>
On Thu, 2018-04-19 at 16:12 -0700, Brian Stark wrote:
> I was comparing different caching techniques using MTRR entries and I
> found something strange. Note the output is from a basic utility that
> uses mmap.
>
> NV Memory:
>
> Write-back
>
> Writes took 2075.993408 Megabytes per second
> Reads took 2130.842529 Megabytes per second No Errors Found
>
> Write-Through
>
> Writes took 55.332256 Megabytes per second
> Reads took 92.310310 Megabytes per second No Errors Found !!!I was
> expecting this number to be the same as Write-back
>
> Uncached
>
> Writes took 55.331089 Megabytes per second
> Reads took 92.315132 Megabytes per second No Errors Found
>
> Regular memory:
>
> Write-back
>
> Writes took 1875.560791 Megabytes per second
> Reads took 2070.452637 Megabytes per second No Errors Found
>
> Write-Through
>
> Writes took 54.903713 Megabytes per second
> Reads took 2106.244629 Megabytes per second No Errors Found !!!This
> is what I expected to see for NV Memory
>
> Uncached
>
> Writes took 54.903923 Megabytes per second
> Reads took 90.150986 Megabytes per second No Errors Found
>
> I am using the same driver (which adds MTRR entries to change caching
> type) there is no physical reason why write through should behave
> differently when using NV Memory. Does anybody on this mailing list
> who may be more familiar with caching techniques know why this might
> me the case?
I reran my old test and did not see this problem. So, I think there is
an issue in your setup that it somehow ended up with UC...
My test driver calls ioremap_wt to an NVDIMM range and access it from
the driver itself. It does not modify MTRR entries.
-Toshi
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
prev parent reply other threads:[~2018-04-20 21:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-19 23:12 Write through caching on NVDIMM Brian Stark
2018-04-20 21:33 ` Kani, Toshi [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=1524259971.2693.432.camel@hpe.com \
--to=toshi.kani@hpe.com \
--cc=brian.stark@sanmina.com \
--cc=linux-nvdimm@lists.01.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 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).