* Christoph Hellwig wrote:
> On Thu, Apr 02, 2015 at 03:11:36PM +, Elliott, Robert (Server Storage)
> wrote:
> > AttrCopyRead IOPS Write IOPS
> > = ==
> > UC memcpy 36 K
On Thu, Apr 02, 2015 at 03:11:36PM +, Elliott, Robert (Server Storage)
wrote:
> Attr CopyRead IOPS Write IOPS
> = ==
> UCmemcpy 36 K22 K
> UCNT rd,wr513 K
g; x...@kernel.org;
> ross.zwis...@linux.intel.com; ax...@kernel.dk; b...@plexistor.com; Kani,
> Toshimitsu
> Subject: Re: another pmem variant V2
>
> On Tue, Mar 31, 2015 at 10:11:29PM +, Elliott, Robert (Server Storage)
> wrote:
> > I used fio to test 4 KiB random read and wr
On Wed, Apr 01, 2015 at 07:33:38PM +, Elliott, Robert (Server Storage)
wrote:
> I triggered a paging error in the memcpy call for a block read
> from system-udevd (actually in a modified memcpy() for the cache
> attribute experiments).
>
> 1. This triggered an illegal schedule() call from a
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Christoph Hellwig
> Sent: Thursday, March 26, 2015 3:33 AM
> To: linux-nvd...@ml01.01.org; linux-fsde...@vger.kernel.org; linux-
> ker...@vger.kernel.org; x...@kernel.
On 03/31/2015 07:16 PM, Christoph Hellwig wrote:
> On Tue, Mar 31, 2015 at 06:14:15PM +0300, Boaz Harrosh wrote:
>> We can not accept it as is right now.
>
> Who is we?
>
>> We have conducted farther tests. And it messes up NUMA.
>
> Only you if you use the memmap option in weird ways.
>
No we
On Tue, Mar 31, 2015 at 10:11:29PM +, Elliott, Robert (Server Storage)
wrote:
> I used fio to test 4 KiB random read and write IOPS
> on a 2-socket x86 DDR4 system. With various cache attributes:
>
> attr readwrite notes
> - -
>
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Christoph Hellwig
> Sent: Thursday, March 26, 2015 3:33 AM
> To: linux-nvd...@ml01.01.org; linux-fsde...@vger.kernel.org; linux-
> ker...@vger.kernel.org; x...@kerne
On Tue, Mar 31, 2015 at 06:44:56PM +0200, Ingo Molnar wrote:
> I'd be fine with that too - mind sending an updated series?
I will send an updated one tonight or early tomorrow.
Btw, do you want to keep the E820_PRAM name instead of E820_PMEM?
Seems like most people either don't care or prefer E82
* Christoph Hellwig wrote:
> On Tue, Mar 31, 2015 at 06:14:15PM +0300, Boaz Harrosh wrote:
> > We can not accept it as is right now.
>
> Who is we?
>
> > We have conducted farther tests. And it messes up NUMA.
>
> Only you if you use the memmap option in weird ways.
>
> Sounds like I should
On Tue, Mar 31, 2015 at 06:14:15PM +0300, Boaz Harrosh wrote:
> We can not accept it as is right now.
Who is we?
> We have conducted farther tests. And it messes up NUMA.
Only you if you use the memmap option in weird ways.
Sounds like I should simply remove the memmap= option so people don't
a
On Tue, Mar 31, 2015 at 01:25:46PM +0300, Boaz Harrosh wrote:
> The problem I see is that if I state a memmap=nn!aa that crosses a NUMA
> boundary then the machine will not boot.
> So BTW for sure I need that "don't merge E820_PMEM ranges" patch because
> otherwise I will not be able to boot if I h
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 su
On 03/31/2015 01:25 PM, Boaz Harrosh wrote:
> On 03/31/2015 12:25 PM, Christoph Hellwig wrote:
<>
> The problem I see is that if I state a memmap=nn!aa that crosses a NUMA
> boundary then the machine will not boot.
> So BTW for sure I need that "don't merge E820_PMEM ranges" patch because
> otherwi
On 03/31/2015 12:25 PM, Christoph Hellwig wrote:
> On Thu, Mar 26, 2015 at 06:57:47PM +0200, Boaz Harrosh wrote:
>> On 03/26/2015 10:32 AM, Christoph Hellwig wrote:
>>> Here is another version of the same trivial pmem driver, because two
>>> obviously aren't enough. The first patch is the same pme
On Thu, Mar 26, 2015 at 06:57:47PM +0200, Boaz Harrosh wrote:
> On 03/26/2015 10:32 AM, Christoph Hellwig wrote:
> > Here is another version of the same trivial pmem driver, because two
> > obviously aren't enough. The first patch is the same pmem driver
> > that Ross posted a short time ago, just
On Thu, Mar 26, 2015 at 07:31:03PM +0200, Boaz Harrosh wrote:
> But I hope you are not ignoring my real problem. any two memmap= ranges
> will halt the boot. Specially if they are dis-contiguous.
not the case here, verified it in various cofigurations.
> Also I need the contiguous variant split i
And here's the patch, sorry:
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 4bd525a..e7bf89e 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -346,7 +346,7 @@ int __init sanitize_e820_map(struct e820entry *biosmap, int
max_nr_map,
* continu
On 03/26/2015 07:18 PM, Christoph Hellwig wrote:
> On Thu, Mar 26, 2015 at 06:57:47PM +0200, Boaz Harrosh wrote:
>> For one this auto discovery of yours is very (very) nice but is a bit
>> inconvenience. Before I would reserve a big chuck on each NUMA range
>> on Kernel's memmap= And then at pmem
On Thu, Mar 26, 2015 at 06:57:47PM +0200, Boaz Harrosh wrote:
> For one this auto discovery of yours is very (very) nice but is a bit
> inconvenience. Before I would reserve a big chuck on each NUMA range
> on Kernel's memmap= And then at pmem map= would slice and dice it
> as I want hot style on
On 03/26/2015 10:32 AM, Christoph Hellwig wrote:
> Here is another version of the same trivial pmem driver, because two
> obviously aren't enough. The first patch is the same pmem driver
> that Ross posted a short time ago, just modified to use platform_devices
> to find the persistant memory regi
21 matches
Mail list logo