* 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
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 an
...@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 write IOPS
on a 2-socket x86 DDR4 system. With various
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
* Christoph Hellwig h...@lst.de wrote:
On Thu, Apr 02, 2015 at 03:11:36PM +, Elliott, Robert (Server Storage)
wrote:
AttrCopyRead IOPS Write IOPS
= ==
UC memcpy 36 K
vger.kernel.org; x...@kernel.org
> Cc: ross.zwis...@linux.intel.com; ax...@kernel.dk; b...@plexistor.com
> Subject: another pmem variant V2
>
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
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
On 04/01/2015 10:50 AM, Ingo Molnar wrote:
>
> * Dan Williams wrote:
>
>> On Tue, Mar 31, 2015 at 10:24 AM, Christoph Hellwig wrote:
>>> 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
* Dan Williams wrote:
> On Tue, Mar 31, 2015 at 10:24 AM, Christoph Hellwig wrote:
> > 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
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
> - -
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
- -
UC
On 04/01/2015 10:50 AM, Ingo Molnar wrote:
* Dan Williams dan.j.willi...@intel.com wrote:
On Tue, Mar 31, 2015 at 10:24 AM, Christoph Hellwig h...@lst.de wrote:
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
* Dan Williams dan.j.willi...@intel.com wrote:
On Tue, Mar 31, 2015 at 10:24 AM, Christoph Hellwig h...@lst.de wrote:
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
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 weird ways
Cc: ross.zwis...@linux.intel.com; ax...@kernel.dk; b...@plexistor.com
Subject: another pmem variant V2
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
vger.kernel.org; x...@kernel.org
> Cc: ross.zwis...@linux.intel.com; ax...@kernel.dk; b...@plexistor.com
> Subject: another pmem variant V2
>
> Here is another version of the same trivial pmem driver, because two
> obviously aren't enough. The first patch is the same pmem driver
> tha
On Tue, Mar 31, 2015 at 10:24 AM, Christoph Hellwig wrote:
> 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
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
* 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
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
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
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
>
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
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,
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 pmem driver
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
otherwise I
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 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
* Christoph Hellwig h...@lst.de 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 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 have
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
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
On Tue, Mar 31, 2015 at 10:24 AM, Christoph Hellwig h...@lst.de wrote:
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
Cc: ross.zwis...@linux.intel.com; ax...@kernel.dk; b...@plexistor.com
Subject: another pmem variant V2
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
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
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,
*
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
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 region instead of hardconding it in the
Kconfig. This
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 region instead of hardconding it in the
Kconfig. This
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 map=
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
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,
*
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
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 region
50 matches
Mail list logo
