:
[ +0.000537] pmem: init 2 devices => 0
...
Printed by pmem modprobe -r:
[ +0.000537] pmem: exit
Signed-off-by: Boaz Harrosh
---
drivers/block/pmem.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c
index 988f384..44d3f33 100644
--- a/driv
:
[ +16.299145] pmem pmem.1.auto: remove
[ +0.011155] pmem pmem.0.auto: remove
Signed-off-by: Boaz Harrosh
---
drivers/block/pmem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c
index 988f384..36017f1 100644
--- a/drivers/block/pmem.c
+++ b
.auto: remove
Signed-off-by: Boaz Harrosh
---
[PATCH 1B] pmem: Add prints at module load/unload
When debugging people's systems it is helpful
to see what went on. The load and unload of pmem is
an important event.
The importance is the number of loaded devices and
error status. The exact
On 04/07/2015 06:19 PM, Christoph Hellwig wrote:
> On Sun, Apr 05, 2015 at 11:50:06AM +0300, Boaz Harrosh wrote:
>> [ +0.000537] pmem: init 2 devices => 0
>>
>> So I have all the information. And I know the driver was actually loaded
>> successfully on the expecte
On 04/07/2015 09:43 AM, Mike Galbraith wrote:
> On Tue, 2015-04-07 at 11:37 +0800, Pengfei Yuan wrote:
>> Hi,
>>
>> I have conducted some experiments to compare kernels built with -O2
>> and -O3. Here are the results:
>>
>> Application Performance O2 Performance O3 Improvement
>> Apache
nges.
But E820_PRAM ranges will have the possibility for struct-page.
That said I have tested with this patch + struct-page and
Tested-by: Boaz Harrosh
Comments below ...
> Revert the change made to account
> E820_PRAM as RAM in e820.c in the commit.
>
> Signed-off-by: Yingh
will have the possibility for struct-page.
That said I have tested with this patch + struct-page and
Tested-by: Boaz Harrosh b...@plexistor.com
Comments below ...
Revert the change made to account
E820_PRAM as RAM in e820.c in the commit.
Signed-off-by: Yinghai Lu ying...@kernel.org
Signed
On 04/07/2015 09:43 AM, Mike Galbraith wrote:
On Tue, 2015-04-07 at 11:37 +0800, Pengfei Yuan wrote:
Hi,
I have conducted some experiments to compare kernels built with -O2
and -O3. Here are the results:
Application Performance O2 Performance O3 Improvement
Apache 127814.14
.auto: remove
Signed-off-by: Boaz Harrosh b...@plexistor.com
---
[PATCH 1B] pmem: Add prints at module load/unload
When debugging people's systems it is helpful
to see what went on. The load and unload of pmem is
an important event.
The importance is the number of loaded devices and
error status
On 04/07/2015 06:19 PM, Christoph Hellwig wrote:
On Sun, Apr 05, 2015 at 11:50:06AM +0300, Boaz Harrosh wrote:
[ +0.000537] pmem: init 2 devices = 0
So I have all the information. And I know the driver was actually loaded
successfully on the expected two regions.
The second number
:
[ +0.000537] pmem: init 2 devices = 0
...
Printed by pmem modprobe -r:
[ +0.000537] pmem: exit
Signed-off-by: Boaz Harrosh b...@plexistor.com
---
drivers/block/pmem.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c
index 988f384..44d3f33
:
[ +16.299145] pmem pmem.1.auto: remove
[ +0.011155] pmem pmem.0.auto: remove
Signed-off-by: Boaz Harrosh b...@plexistor.com
---
drivers/block/pmem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c
index 988f384..36017f1 100644
--- a/drivers/block
On 04/05/2015 11:06 PM, Yinghai Lu wrote:
> On Sun, Apr 5, 2015 at 2:18 AM, Boaz Harrosh wrote:
<>
>> Hi Yinghai, Toshi
>>
>> In my old patches I did not have these updates as well, and everything
>> was very much usable, for a long time.
>>
>
On 04/05/2015 11:06 PM, Yinghai Lu wrote:
On Sun, Apr 5, 2015 at 2:18 AM, Boaz Harrosh b...@plexistor.com wrote:
Hi Yinghai, Toshi
In my old patches I did not have these updates as well, and everything
was very much usable, for a long time.
However. I actually liked these changes
On 04/03/2015 08:12 PM, Yinghai Lu wrote:
> On Fri, Apr 3, 2015 at 9:14 AM, Toshi Kani wrote:
>> On Wed, 2015-04-01 at 09:12 +0200, Christoph Hellwig wrote:
>> :
>>> @@ -748,7 +758,7 @@ u64 __init early_reserve_e820(u64 size, u64 align)
>>> /*
>>> * Find the highest page frame number we have
On 04/02/2015 07:44 PM, Christoph Hellwig wrote:
> On Thu, Apr 02, 2015 at 09:01:14AM -0700, Dan Williams wrote:
If anything I think these should be dev_dbg().
>>>
>>> We do not have a dev at any of this point, and it does not
>>> belong to any specific device.
>>
>> Ah, true this is prior to
On 04/02/2015 07:44 PM, Christoph Hellwig wrote:
On Thu, Apr 02, 2015 at 09:01:14AM -0700, Dan Williams wrote:
If anything I think these should be dev_dbg().
We do not have a dev at any of this point, and it does not
belong to any specific device.
Ah, true this is prior to the driver
On 04/03/2015 08:12 PM, Yinghai Lu wrote:
On Fri, Apr 3, 2015 at 9:14 AM, Toshi Kani toshi.k...@hp.com wrote:
On Wed, 2015-04-01 at 09:12 +0200, Christoph Hellwig wrote:
:
@@ -748,7 +758,7 @@ u64 __init early_reserve_e820(u64 size, u64 align)
/*
* Find the highest page frame number we
On 04/02/2015 06:39 PM, Dan Williams wrote:
> On Thu, Apr 2, 2015 at 8:31 AM, Boaz Harrosh wrote:
>> Hi Christoph, Ingo
>>
>> Please consider this small patch below just a small print at module
>> load/unload so to know at user systems how things progressed.
>&
Hi Christoph, Ingo
Please consider this small patch below just a small print at module
load/unload so to know at user systems how things progressed.
As it is now, we know nothing. For any other disk kind we have two
tuns of prints.
---
From: Boaz Harrosh
Date: Thu, 2 Apr 2015 16:43:48 +0300
On 04/02/2015 12:30 PM, Christoph Hellwig wrote:
> On Wed, Apr 01, 2015 at 05:25:22PM +0300, Boaz Harrosh wrote:
>> pfn = PFN_DOWN(ei->addr + ei->size);
>>
>> -switch (ei->type) {
>> -case E820_RAM:
>> -
On 04/02/2015 12:30 PM, Christoph Hellwig wrote:
On Wed, Apr 01, 2015 at 05:25:22PM +0300, Boaz Harrosh wrote:
pfn = PFN_DOWN(ei-addr + ei-size);
-switch (ei-type) {
-case E820_RAM:
-case E820_PRAM:
-case E820_RESERVED_KERN
Hi Christoph, Ingo
Please consider this small patch below just a small print at module
load/unload so to know at user systems how things progressed.
As it is now, we know nothing. For any other disk kind we have two
tuns of prints.
---
From: Boaz Harrosh b...@plexistor.com
Date: Thu, 2 Apr 2015
On 04/02/2015 06:39 PM, Dan Williams wrote:
On Thu, Apr 2, 2015 at 8:31 AM, Boaz Harrosh b...@plexistor.com wrote:
Hi Christoph, Ingo
Please consider this small patch below just a small print at module
load/unload so to know at user systems how things progressed.
As it is now, we know
; This patch contains the initial driver from Ross Zwisler, with
> various changes from Boaz Harrosh and me.
>
> Signed-off-by: Ross Zwisler
> [hch: convert to use a platform_device for discovery, fix partition
> support, merged various patches from Boaz]
> Signed-off-by: Chris
(Actually it will be the
opposite right). Can we actually define swap on a /dev/pmemX ? ;-)
Signed-off-by: Boaz Harrosh
---
Documentation/kernel-parameters.txt | 6 ++
arch/x86/kernel/e820.c | 20 +---
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/Doc
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 t
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
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
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
it will be the
opposite right). Can we actually define swap on a /dev/pmemX ? ;-)
Signed-off-by: Boaz Harrosh b...@plexistor.com
---
Documentation/kernel-parameters.txt | 6 ++
arch/x86/kernel/e820.c | 20 +---
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git
.
This patch contains the initial driver from Ross Zwisler, with
various changes from Boaz Harrosh and me.
Signed-off-by: Ross Zwisler ross.zwis...@linux.intel.com
[hch: convert to use a platform_device for discovery, fix partition
support, merged various patches from Boaz]
Signed-off
On 03/31/2015 06:30 PM, Dan Williams wrote:
> On Tue, Mar 31, 2015 at 8:24 AM, Boaz Harrosh wrote:
>> On 03/31/2015 06:17 PM, Dan Williams wrote:
>>> On Tue, Mar 31, 2015 at 6:27 AM, Boaz Harrosh wrote:
>>>>
>>>> Some error checks had unlikely so
On 03/31/2015 06:17 PM, Dan Williams wrote:
> On Tue, Mar 31, 2015 at 6:27 AM, Boaz Harrosh wrote:
>>
>> Some error checks had unlikely some did not. Put unlikely
>> on all error handling paths.
>> (I like unlikely for error paths specially for readability)
>
>
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:
On 03/31/2015 01:25 PM, Boaz Harrosh wrote:
<>
>
> And one last issue. I have some configuration "hardness" with the
> memmap=nn!aa Kernel command line API, it was better for me with the
> pmem map= module param. Will you be OK if I split pmem_probe() into
> calling
On 03/27/2015 01:31 AM, Dan Williams wrote:
> On Thu, Mar 26, 2015 at 10:02 AM, Boaz Harrosh wrote:
>>
>> Christoph why did you choose the fat and ugly version of
>> pmem.c beats me.
>
> Boaz, I am so very tired of your snide commentary. It severely
> detracts fr
The driver is no longer similar to brd.c.
Christoph completely changed the 2nd half of the patch
and I completely removed the 1st half.
pmem is its own thing.
Also added Copyright of Christoph and me. Feel free
to remove if it is not so.
Signed-off-by: Boaz Harrosh
---
drivers/block/pmem.c
Remove SECTOR_SHIFT. It is defined in 6 other places
in the Kernel. I do not like a new one. 9 is used through
out, including block core. I do not like pmem to blasphemy
more than needed.
Signed-off-by: Boaz Harrosh
---
drivers/block/pmem.c | 6 +-
1 file changed, 1 insertion(+), 5
Some error checks had unlikely some did not. Put unlikely
on all error handling paths.
(I like unlikely for error paths specially for readability)
Also use bio_data_dir() to extract away the READA flag
Signed-off-by: Boaz Harrosh
---
drivers/block/pmem.c | 16 +++-
1 file changed
Remove getgeo. It is not needed for modern fdisk and was never
needed for libgparted and cfdisk.
Signed-off-by: Boaz Harrosh
---
drivers/block/pmem.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c
index 545b13b..dcb524f 100644
does these checks and I did not see these
checks done in other drivers.
Signed-off-by: Boaz Harrosh
---
drivers/block/pmem.c | 112 ++-
1 file changed, 22 insertions(+), 90 deletions(-)
diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c
index
need this patch for now. I have booting
problems on some machines, when a contiguous pmem range crosses
a NUMA boundary.
Signed-off-by: Boaz Harrosh
---
arch/x86/kernel/e820.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index
On 03/31/2015 12:25 PM, Christoph Hellwig wrote:
>
> Any news? I'd really like to resend this ASAP to get it into 4.1..
>
Hi Christoph, list
I'm sending in one SQUASHME patch to the first e820 patch.
And few other patches to the initial pmem.c driver submission.
Please squash those patches,
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_PME
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.
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 03/27/2015 01:31 AM, Dan Williams wrote:
On Thu, Mar 26, 2015 at 10:02 AM, Boaz Harrosh b...@plexistor.com wrote:
Christoph why did you choose the fat and ugly version of
pmem.c beats me.
Boaz, I am so very tired of your snide commentary. It severely
detracts from the technical merit
On 03/31/2015 01:25 PM, Boaz Harrosh wrote:
And one last issue. I have some configuration hardness with the
memmap=nn!aa Kernel command line API, it was better for me with the
pmem map= module param. Will you be OK if I split pmem_probe() into
calling pmem_alloc(addr, length), so I can keep
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 06:30 PM, Dan Williams wrote:
On Tue, Mar 31, 2015 at 8:24 AM, Boaz Harrosh b...@plexistor.com wrote:
On 03/31/2015 06:17 PM, Dan Williams wrote:
On Tue, Mar 31, 2015 at 6:27 AM, Boaz Harrosh b...@plexistor.com wrote:
Some error checks had unlikely some did not. Put unlikely
On 03/31/2015 06:17 PM, Dan Williams wrote:
On Tue, Mar 31, 2015 at 6:27 AM, Boaz Harrosh b...@plexistor.com wrote:
Some error checks had unlikely some did not. Put unlikely
on all error handling paths.
(I like unlikely for error paths specially for readability)
unlikely
On 03/31/2015 12:25 PM, Christoph Hellwig wrote:
Any news? I'd really like to resend this ASAP to get it into 4.1..
Hi Christoph, list
I'm sending in one SQUASHME patch to the first e820 patch.
And few other patches to the initial pmem.c driver submission.
Please squash those patches,
I please need this patch for now. I have booting
problems on some machines, when a contiguous pmem range crosses
a NUMA boundary.
Signed-off-by: Boaz Harrosh b...@plexistor.com
---
arch/x86/kernel/e820.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/e820.c b
does these checks and I did not see these
checks done in other drivers.
Signed-off-by: Boaz Harrosh b...@plexistor.com
---
drivers/block/pmem.c | 112 ++-
1 file changed, 22 insertions(+), 90 deletions(-)
diff --git a/drivers/block/pmem.c b/drivers
Remove getgeo. It is not needed for modern fdisk and was never
needed for libgparted and cfdisk.
Signed-off-by: Boaz Harrosh b...@plexistor.com
---
drivers/block/pmem.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c
index 545b13b
Some error checks had unlikely some did not. Put unlikely
on all error handling paths.
(I like unlikely for error paths specially for readability)
Also use bio_data_dir() to extract away the READA flag
Signed-off-by: Boaz Harrosh b...@plexistor.com
---
drivers/block/pmem.c | 16
Remove SECTOR_SHIFT. It is defined in 6 other places
in the Kernel. I do not like a new one. 9 is used through
out, including block core. I do not like pmem to blasphemy
more than needed.
Signed-off-by: Boaz Harrosh b...@plexistor.com
---
drivers/block/pmem.c | 6 +-
1 file changed, 1
The driver is no longer similar to brd.c.
Christoph completely changed the 2nd half of the patch
and I completely removed the 1st half.
pmem is its own thing.
Also added Copyright of Christoph and me. Feel free
to remove if it is not so.
Signed-off-by: Boaz Harrosh b...@plexistor.com
On 03/29/2015 11:02 AM, Boaz Harrosh wrote:
> On 03/26/2015 09:32 PM, Dave Chinner wrote:
<>
> I think that ->direct_access should not be any different then
> any other block-device access, ie allow to sleep.
>
BTW: Matthew you yourself have said that after a page-load of
On 03/26/2015 09:32 PM, Dave Chinner wrote:
<>
>> I'm leaning towards the latter. But I'm not sure what GFP flags to
>> recommend that brd use ... GFP_NOWAIT | __GFP_ZERO, perhaps?
>
> What, so we get random IO failures under memory pressure?
>
> I really think we should allow .direct_access to
On 03/29/2015 11:02 AM, Boaz Harrosh wrote:
On 03/26/2015 09:32 PM, Dave Chinner wrote:
I think that -direct_access should not be any different then
any other block-device access, ie allow to sleep.
BTW: Matthew you yourself have said that after a page-load of memcpy
a user should call
On 03/26/2015 09:32 PM, Dave Chinner wrote:
I'm leaning towards the latter. But I'm not sure what GFP flags to
recommend that brd use ... GFP_NOWAIT | __GFP_ZERO, perhaps?
What, so we get random IO failures under memory pressure?
I really think we should allow .direct_access to sleep. It
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 memm
is used through
out, including block core. I do not like pmem to blasphemy
more than needed.
* More style stuff ...
Please squash into your initial submission
Signed-off-by: Boaz Harrosh
---
drivers/block/pmem.c | 137 +++
1 file changed, 28
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
On 03/26/2015 06:02 PM, Dan Williams wrote:
> On Thu, Mar 26, 2015 at 8:49 AM, Boaz Harrosh wrote:
>> On 03/26/2015 11:34 AM, Christoph Hellwig wrote:
>>> +/*
>>> + * This is a non-standardized way to represent ADR or NVDIMM regions that
>>> + * persist ov
On 03/26/2015 11:34 AM, Christoph Hellwig wrote:
<>
Please re-post this patch stand alone because git am on this will
Give me the wrong title and commit message
small comments ...
> From: Christoph Hellwig
> Date: Wed, 25 Mar 2015 12:24:11 +0100
> Subject: x86: add support for the non-standard
On 03/26/2015 04:12 PM, Dan Williams wrote:
> On Thu, Mar 26, 2015 at 1:32 AM, Christoph Hellwig wrote:
>> From: Ross Zwisler
>>
Dan something is Broken with you mailer program it keeps dropping the
CC when sending replies.
For example Both me and Ross who were on CC got dropped, Jens Axboe
On 03/26/2015 06:00 AM, Elliott, Robert (Server Storage) wrote:
>
>
>> -Original Message-
>> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
>> ow...@vger.kernel.org] On Behalf Of Andy Lutomirski
>> Sent: Wednesday, March 18, 2015 1:07 PM
>
is used through
out, including block core. I do not like pmem to blasphemy
more than needed.
* More style stuff ...
Please squash into your initial submission
Signed-off-by: Boaz Harrosh b...@plexistor.com
---
drivers/block/pmem.c | 137 +++
1
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 03/26/2015 06:02 PM, Dan Williams wrote:
On Thu, Mar 26, 2015 at 8:49 AM, Boaz Harrosh b...@plexistor.com wrote:
On 03/26/2015 11:34 AM, Christoph Hellwig wrote:
+/*
+ * This is a non-standardized way to represent ADR or NVDIMM regions that
+ * persist over a reboot. The kernel
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
On 03/26/2015 06:00 AM, Elliott, Robert (Server Storage) wrote:
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Andy Lutomirski
Sent: Wednesday, March 18, 2015 1:07 PM
To: Boaz Harrosh
Cc: Matthew Wilcox; Ross
On 03/26/2015 11:34 AM, Christoph Hellwig wrote:
Please re-post this patch stand alone because git am on this will
Give me the wrong title and commit message
small comments ...
From: Christoph Hellwig h...@lst.de
Date: Wed, 25 Mar 2015 12:24:11 +0100
Subject: x86: add support for the
On 03/26/2015 04:12 PM, Dan Williams wrote:
On Thu, Mar 26, 2015 at 1:32 AM, Christoph Hellwig h...@lst.de wrote:
From: Ross Zwisler ross.zwis...@linux.intel.com
Dan something is Broken with you mailer program it keeps dropping the
CC when sending replies.
For example Both me and Ross who
On 03/23/2015 05:19 PM, Rik van Riel wrote:
>>> Michael Tsirkin and I have been doing some thinking about what
>>> it would take to allocate struct pages per 2MB area permanently,
>>> and allocate additional struct pages for 4kB pages on demand,
>>> when a 2MB area is broken up into 4kB pages.
>>
On 03/23/2015 05:19 PM, Rik van Riel wrote:
Michael Tsirkin and I have been doing some thinking about what
it would take to allocate struct pages per 2MB area permanently,
and allocate additional struct pages for 4kB pages on demand,
when a 2MB area is broken up into 4kB pages.
My thoughts
On 03/22/2015 07:22 PM, Dan Williams wrote:
> On Sun, Mar 22, 2015 at 10:06 AM, Boaz Harrosh wrote:
<>
>>
>> Moving to pfn's only means that all this unnamed code above that
>> "relies on struct page being PAGE_SIZE" is now not allowed to
>> interfaced
On 03/19/2015 10:59 PM, Dan Williams wrote:
>
> At least for block-i/o it seems the only place we really need struct
> page infrastructure is for kmap(). Given we already need a kmap_pfn()
> solution for option 2 a "dynamic allocation" stop along that
> development path may just naturally fall
On 03/20/2015 11:08 PM, Rik van Riel wrote:
> On 03/20/2015 04:31 PM, Matthew Wilcox wrote:
<>
>> There's a lot of code out there that relies on struct page being PAGE_SIZE
>> bytes. I'm cool with replacing 'struct page' with 'struct superpage'
>> [1] in the biovec and auditing all of the code
On 03/19/2015 08:17 PM, Christoph Hellwig wrote:
<>
>
> In addition to the options there's also a time line. At least for the
> short term where we want to get something going 1a seems like the
> absolutely be option. It works perfectly fine for the lots of small
> capacity dram-like nvdimms,
On 03/20/2015 10:31 PM, Matthew Wilcox wrote:
<>
>
> There's a lot of code out there that relies on struct page being PAGE_SIZE
> bytes.
Not so much really. Not at the lower end of the stack. You can actually feed
a
vp = kmalloc(64K);
bv_page = virt_to_page(vp)
bv_len
On 03/20/2015 06:21 PM, Rik van Riel wrote:
> On 03/19/2015 09:43 AM, Matthew Wilcox wrote:
>
>> 1. Construct struct pages for persistent memory
>> 1a. Permanently
>> 1b. While the pages are under I/O
>
> Michael Tsirkin and I have been doing some thinking about what
> it would take to allocate
On 03/20/2015 05:56 PM, Rik van Riel wrote:
> On 03/18/2015 10:38 AM, Boaz Harrosh wrote:
>> On 03/18/2015 03:06 PM, Matthew Wilcox wrote:
>
>>>> I'm not the one afraid of hard work, if it was for a good cause, but for
>>>> what?
>>>> really for
On 03/19/2015 09:59 PM, Andrew Morton wrote:
> On Thu, 19 Mar 2015 17:54:15 +0200 Boaz Harrosh wrote:
>
>> On 03/19/2015 03:43 PM, Matthew Wilcox wrote:
>> <>
>>>
>>> Dan missed "Support O_DIRECT to a mapped DAX file". More generally, if w
On 03/19/2015 09:59 PM, Andrew Morton wrote:
On Thu, 19 Mar 2015 17:54:15 +0200 Boaz Harrosh b...@plexistor.com wrote:
On 03/19/2015 03:43 PM, Matthew Wilcox wrote:
Dan missed Support O_DIRECT to a mapped DAX file. More generally, if we
want to be able to do any kind of I/O directly
On 03/20/2015 05:56 PM, Rik van Riel wrote:
On 03/18/2015 10:38 AM, Boaz Harrosh wrote:
On 03/18/2015 03:06 PM, Matthew Wilcox wrote:
I'm not the one afraid of hard work, if it was for a good cause, but for
what?
really for what? The block layer, and RDMA, and networking, and spline
On 03/20/2015 06:21 PM, Rik van Riel wrote:
On 03/19/2015 09:43 AM, Matthew Wilcox wrote:
1. Construct struct pages for persistent memory
1a. Permanently
1b. While the pages are under I/O
Michael Tsirkin and I have been doing some thinking about what
it would take to allocate struct
On 03/19/2015 08:17 PM, Christoph Hellwig wrote:
In addition to the options there's also a time line. At least for the
short term where we want to get something going 1a seems like the
absolutely be option. It works perfectly fine for the lots of small
capacity dram-like nvdimms, and it
On 03/20/2015 11:08 PM, Rik van Riel wrote:
On 03/20/2015 04:31 PM, Matthew Wilcox wrote:
There's a lot of code out there that relies on struct page being PAGE_SIZE
bytes. I'm cool with replacing 'struct page' with 'struct superpage'
[1] in the biovec and auditing all of the code which
On 03/19/2015 10:59 PM, Dan Williams wrote:
At least for block-i/o it seems the only place we really need struct
page infrastructure is for kmap(). Given we already need a kmap_pfn()
solution for option 2 a dynamic allocation stop along that
development path may just naturally fall out.
On 03/20/2015 10:31 PM, Matthew Wilcox wrote:
There's a lot of code out there that relies on struct page being PAGE_SIZE
bytes.
Not so much really. Not at the lower end of the stack. You can actually feed
a
vp = kmalloc(64K);
bv_page = virt_to_page(vp)
bv_len = 64k
On 03/22/2015 07:22 PM, Dan Williams wrote:
On Sun, Mar 22, 2015 at 10:06 AM, Boaz Harrosh b...@plexistor.com wrote:
Moving to pfn's only means that all this unnamed code above that
relies on struct page being PAGE_SIZE is now not allowed to
interfaced with bio and sg list. Which in current
e with this patch. (So many of them, bread crumbs of copy/paste
for you ;0)
Reviewed-by: Boaz Harrosh
> fs/affs/affs.h | 2 +-
> fs/befs/befs.h | 2 +-
> fs/coda/coda_linux.h| 2 +-
> fs/hfs/hfs_fs.h | 2 +-
> fs/hfsplus/hfsplus_fs.h
On 03/19/2015 03:43 PM, Matthew Wilcox wrote:
<>
>
> Dan missed "Support O_DIRECT to a mapped DAX file". More generally, if we
> want to be able to do any kind of I/O directly to persistent memory,
> and I think we do, we need to do one of:
>
> 1. Construct struct pages for persistent memory
>
On 03/18/2015 07:43 PM, Ross Zwisler wrote:
> On Thu, 2015-03-05 at 13:55 +0200, Boaz Harrosh wrote:
>> From: Ross Zwisler
>>
>> PMEM is a new driver That supports any physical contiguous iomem range
>> as a single block device. The driver has support for as many as
On 03/18/2015 07:43 PM, Ross Zwisler wrote:
On Thu, 2015-03-05 at 13:55 +0200, Boaz Harrosh wrote:
From: Ross Zwisler ross.zwis...@linux.intel.com
PMEM is a new driver That supports any physical contiguous iomem range
as a single block device. The driver has support for as many as needed
301 - 400 of 1123 matches
Mail list logo
