linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: Boaz Harrosh <boaz@plexistor.com>,
	"Elliott, Robert (Persistent Memory)" <elliott@hpe.com>,
	"dan.j.williams@intel.com" <dan.j.williams@intel.com>
Cc: "Knippers, Linda" <linda.knippers@hpe.com>,
	"util-linux@vger.kernel.org" <util-linux@vger.kernel.org>,
	"Kani, Toshimitsu" <toshi.kani@hpe.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>
Subject: Re: mkfs.btrfs cannot find rotational file for SSD detection for a pmem device
Date: Wed, 9 Sep 2015 08:40:23 -0400	[thread overview]
Message-ID: <55F028B7.9080707@gmail.com> (raw)
In-Reply-To: <55F02239.3090809@plexistor.com>

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

On 2015-09-09 08:12, Boaz Harrosh wrote:
> On 09/09/2015 02:28 PM, Austin S Hemmelgarn wrote:
>> On 2015-09-08 16:00, Elliott, Robert (Persistent Memory) wrote:
> <>
>
>> this may actually make things slower (the particular effect of SSD mode
>> is that it tries to spread allocations out as much as possible, as this
>> helps with wear-leveling on many SSD's).
>>
>
> For DRAM based NvDIMM it matters not at all. For Flash based or the new
> 3d Xpoint it is a plus, so no harm in leaving it in
>
Looking at it from another perspective however, a lot of modern RAM 
modules will stripe the bits across multiple chips to improve 
performance.  In such a situation, BTRFS making the effort to spread out 
the allocation as much as possible may have an impact because that 
allocation path is slower than the regular one (not by much, but even a 
few microseconds can make a difference when it is getting called a lot).



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

  reply	other threads:[~2015-09-09 12:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-06 17:51 mkfs.btrfs cannot find rotational file for SSD detection for a pmem device Elliott, Robert (Persistent Memory)
2015-09-08 12:56 ` Austin S Hemmelgarn
2015-09-08 20:00   ` Elliott, Robert (Persistent Memory)
2015-09-09 11:28     ` Austin S Hemmelgarn
2015-09-09 12:12       ` Boaz Harrosh
2015-09-09 12:40         ` Austin S Hemmelgarn [this message]
2015-09-09 13:07           ` Boaz Harrosh

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=55F028B7.9080707@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=boaz@plexistor.com \
    --cc=dan.j.williams@intel.com \
    --cc=elliott@hpe.com \
    --cc=linda.knippers@hpe.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-nvdimm@ml01.01.org \
    --cc=toshi.kani@hpe.com \
    --cc=util-linux@vger.kernel.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).