* 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
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 we
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 o
* 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
> - -
>
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
>
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 instead
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
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 allows
25 matches
Mail list logo
