From: Boaz Harrosh <boaz@plexistor.com>
To: Christoph Hellwig <hch@lst.de>, Boaz Harrosh <boaz@plexistor.com>
Cc: linux-nvdimm@ml01.01.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, x86@kernel.org,
ross.zwisler@linux.intel.com, axboe@kernel.dk
Subject: Re: another pmem variant V2
Date: Tue, 31 Mar 2015 18:14:15 +0300 [thread overview]
Message-ID: <551AB9C7.6020505@plexistor.com> (raw)
In-Reply-To: <20150331092526.GA25958@lst.de>
On 03/31/2015 12:25 PM, Christoph Hellwig wrote:
> On Thu, Mar 26, 2015 at 06:57:47PM +0200, Boaz Harrosh wrote:
<>
>
> Any news? I'd really like to resend this ASAP to get it into 4.1..
Hi Christoph
I hate to be bearer of bad news but we have a problem with the
e820 patch:
x86: add support for the non-standard protected e820 type
We can not accept it as is right now.
We have conducted farther tests. And it messes up NUMA.
All the below is based on your latest patches on top of 4.0-rc5
Before any modprobe of pmem.ko, just a clean boot.
In the same exact Kernel, if you use memmap=nn!aa ie add "type-12"
section we have below problems, but if we do memmap=nn\$aa ie add
"reserved" section then everything is fine.
[With my old e820 patches it all works fine because it is closer
to the memmap=nn\$aa "reserved" section way]
The problems we see in a NUMA machine.
* On some machines we cannot boot if a single memmap=nn!aa crosses
a NUMA boundary.
Some VMs sometime boot sometimes do not. Some VMs never boot.
Some machines boot just fine.
Doing memmap=nn1!aa1,nn2!aa2 where the split is at the NUMA
boundary will enable all machines to boot
* Regardless if we use memmap=nn!aa crossing a NUMA boundary or
if we do memmap=nn1!aa1,nn2!aa2 the output of
cat /sys/devices/system/node/node1/meminfo
Is all ZEROs. Yes very scary everything is ZERO. Even though
the dmseg prints show the correct numbers the above
node1/meminfo is broken.
If with the same Kernel we do memmap=nn\$aa then everything
is clean.
So something in the way we defined our new type-12 region
upsets the NUMA code. And we need farther investigation.
Perhaps you would like to start with my e820 much more conservative
fix, that makes type-12 memory behave exactly as reserved memory.
And go from there, step by step. Until we fix the problem above.
So we can submit something like that for 4.1.
Talk to me, tell me what you need me to experiment with. Should I try
your platform device way but based on my e820 fix? how can I please
help push this through?
Thanks
Boaz
next prev parent reply other threads:[~2015-03-31 15:14 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-26 8:32 another pmem variant V2 Christoph Hellwig
2015-03-26 8:32 ` [PATCH 1/3] pmem: Initial version of persistent memory driver Christoph Hellwig
2015-03-26 14:12 ` [Linux-nvdimm] " Dan Williams
2015-03-26 14:35 ` Christoph Hellwig
2015-03-26 21:37 ` Ross Zwisler
2015-03-26 14:52 ` Boaz Harrosh
2015-03-26 15:59 ` Dan Williams
2015-03-26 8:32 ` [PATCH 2/3] x86: add a is_e820_ram() helper Christoph Hellwig
2015-03-26 9:02 ` Ingo Molnar
2015-03-26 9:34 ` Christoph Hellwig
2015-03-26 10:04 ` Ingo Molnar
2015-03-26 10:19 ` Christoph Hellwig
2015-03-26 10:28 ` Ingo Molnar
2015-03-26 10:29 ` Christoph Hellwig
2015-03-26 15:49 ` Boaz Harrosh
2015-03-26 16:02 ` [Linux-nvdimm] " Dan Williams
2015-03-26 16:07 ` Boaz Harrosh
2015-03-26 16:43 ` Christoph Hellwig
2015-03-26 18:46 ` Elliott, Robert (Server Storage)
2015-03-26 19:25 ` [Linux-nvdimm] " Dan Williams
2015-03-26 20:53 ` Ross Zwisler
2015-03-26 22:59 ` Yinghai Lu
2015-03-27 8:10 ` Christoph Hellwig
2015-03-26 8:32 ` [PATCH 3/3] x86: add support for the non-standard protected e820 type Christoph Hellwig
2015-03-26 16:57 ` another pmem variant V2 Boaz Harrosh
2015-03-26 17:02 ` [PATCH] SQUASHME: Streamline pmem.c Boaz Harrosh
2015-03-26 17:23 ` Christoph Hellwig
2015-03-26 22:17 ` Ross Zwisler
2015-03-26 22:22 ` Ross Zwisler
2015-03-26 23:31 ` [Linux-nvdimm] " Dan Williams
2015-03-31 13:44 ` Boaz Harrosh
2015-03-26 17:18 ` another pmem variant V2 Christoph Hellwig
2015-03-26 17:31 ` Boaz Harrosh
2015-03-26 18:38 ` Christoph Hellwig
2015-03-31 9:25 ` Christoph Hellwig
2015-03-31 10:25 ` Boaz Harrosh
2015-03-31 10:31 ` Boaz Harrosh
2015-03-31 14:21 ` [RFC] SQUASHME: pmem: Split up pmem_probe from pmem_alloc Boaz Harrosh
2015-03-31 16:10 ` Christoph Hellwig
2015-03-31 16:08 ` another pmem variant V2 Christoph Hellwig
2015-03-31 13:18 ` [SQUASHME 0/6] Streamline of Initial pmem submission Boaz Harrosh
2015-03-31 13:23 ` [PATCH 1/6] SQUASHME: Don't let e820_PMEM sections Boaz Harrosh
2015-03-31 17:16 ` [Linux-nvdimm] " Brooks, Adam J
2015-03-31 13:24 ` [PATCH 2/6] SQUASHME: pmem: Remove getgeo Boaz Harrosh
2015-03-31 13:25 ` [PATCH 3/6] SQUASHME: pmem: Streamline pmem driver Boaz Harrosh
2015-03-31 13:27 ` [PATCH 4/6] SQUSHME: pmem: Micro cleaning Boaz Harrosh
2015-03-31 15:17 ` [Linux-nvdimm] " Dan Williams
2015-03-31 15:24 ` Boaz Harrosh
2015-03-31 15:30 ` Dan Williams
2015-03-31 15:43 ` Boaz Harrosh
2015-03-31 19:40 ` Matthew Wilcox
2015-03-31 13:28 ` [PATCH 5/6] SQUASHME: pmem: Remove SECTOR_SHIFT Boaz Harrosh
2015-03-31 13:33 ` [PATCH 6/6] SQUASHME: pmem: Remove "... based on brd.c" + Copyright Boaz Harrosh
2015-03-31 15:14 ` Boaz Harrosh [this message]
2015-03-31 16:16 ` another pmem variant V2 Christoph Hellwig
2015-03-31 16:44 ` Ingo Molnar
2015-03-31 17:24 ` Christoph Hellwig
2015-03-31 17:33 ` [Linux-nvdimm] " Dan Williams
2015-04-01 7:50 ` Ingo Molnar
2015-04-01 8:06 ` Boaz Harrosh
2015-04-01 12:49 ` Boaz Harrosh
2015-03-31 22:11 ` Elliott, Robert (Server Storage)
2015-04-01 7:26 ` Christoph Hellwig
2015-04-02 15:11 ` Elliott, Robert (Server Storage)
2015-04-02 16:41 ` Christoph Hellwig
2015-04-02 18:03 ` Ingo Molnar
2015-04-01 19:33 ` Elliott, Robert (Server Storage)
2015-04-02 9:37 ` Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2015-03-26 18:38 Christoph Hellwig
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=551AB9C7.6020505@plexistor.com \
--to=boaz@plexistor.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@ml01.01.org \
--cc=ross.zwisler@linux.intel.com \
--cc=x86@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).