On Thu, Aug 13, 2015 at 10:35 AM, Matthew Wilcox wrote:
> On Wed, Aug 12, 2015 at 11:01:09PM -0400, Dan Williams wrote:
>> +static inline __pfn_t page_to_pfn_t(struct page *page)
>> +{
>> + __pfn_t pfn = { .val = page_to_pfn(page) << PAGE_SHIFT, };
>> +
>> + return pfn;
>> +}
>
> static
On 08/13/2015 07:48 AM, Boaz Harrosh wrote:
> There is already an object that holds a relationship of physical
> to Kernel-virtual. It is called a memory-section. Why not just
> widen its definition?
Memory sections are purely there to map physical address ranges back to
metadata about them.
On Wed, Aug 12, 2015 at 11:01:09PM -0400, Dan Williams wrote:
> +static inline __pfn_t page_to_pfn_t(struct page *page)
> +{
> + __pfn_t pfn = { .val = page_to_pfn(page) << PAGE_SHIFT, };
> +
> + return pfn;
> +}
static inline __pfn_t page_to_pfn_t(struct page *page)
{
__pfn_t
On 08/13/2015 05:48 PM, Boaz Harrosh wrote:
<>
> There is already an object that holds a relationship of physical
> to Kernel-virtual. It is called a memory-section. Why not just
> widen its definition?
>
BTW: Regarding the "widen its definition"
I was thinking of two possible new models here:
On 08/13/2015 05:41 PM, Christoph Hellwig wrote:
> On Thu, Aug 13, 2015 at 04:23:38PM +0300, Boaz Harrosh wrote:
>>> DAX as is is races against pmem unbind. A synchronization cost must
>>> be paid somewhere to make sure the memremap() mapping is still valid.
>>
>> Sorry for being so slow, is
On 08/13/2015 05:37 PM, Christoph Hellwig wrote:
> Hi Boaz,
>
> can you please fix your quoting? I read down about 10 pages but still
> couldn't find a comment from you. For now I gave up on this mail.
>
Sorry here:
> +void *kmap_atomic_pfn_t(__pfn_t pfn)
> +{
> + struct page *page =
On Thu, Aug 13, 2015 at 04:23:38PM +0300, Boaz Harrosh wrote:
> > DAX as is is races against pmem unbind. A synchronization cost must
> > be paid somewhere to make sure the memremap() mapping is still valid.
>
> Sorry for being so slow, is what I asked. what is exactly "pmem unbind" ?
>
>
Hi Boaz,
can you please fix your quoting? I read down about 10 pages but still
couldn't find a comment from you. For now I gave up on this mail.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info
On 08/13/2015 03:57 PM, Dan Williams wrote:
<>
> This is explicitly addressed in the changelog, repeated here:
>
>> The __pfn_t to resource lookup is indeed inefficient walking of a linked
>> list,
>> but there are two mitigating factors:
>>
>> 1/ The number of persistent memory ranges is
On Wed, Aug 12, 2015 at 10:58 PM, Boaz Harrosh wrote:
> On 08/13/2015 06:01 AM, Dan Williams wrote:
[..]
>> +void *kmap_atomic_pfn_t(__pfn_t pfn)
>> +{
>> + struct page *page = __pfn_t_to_page(pfn);
>> + resource_size_t addr;
>> + struct kmap *kmap;
>> +
>> + rcu_read_lock();
>> +
On Wed, Aug 12, 2015 at 10:58 PM, Boaz Harrosh b...@plexistor.com wrote:
On 08/13/2015 06:01 AM, Dan Williams wrote:
[..]
+void *kmap_atomic_pfn_t(__pfn_t pfn)
+{
+ struct page *page = __pfn_t_to_page(pfn);
+ resource_size_t addr;
+ struct kmap *kmap;
+
+ rcu_read_lock();
On 08/13/2015 03:57 PM, Dan Williams wrote:
This is explicitly addressed in the changelog, repeated here:
The __pfn_t to resource lookup is indeed inefficient walking of a linked
list,
but there are two mitigating factors:
1/ The number of persistent memory ranges is bounded by the
Hi Boaz,
can you please fix your quoting? I read down about 10 pages but still
couldn't find a comment from you. For now I gave up on this mail.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Thu, Aug 13, 2015 at 04:23:38PM +0300, Boaz Harrosh wrote:
DAX as is is races against pmem unbind. A synchronization cost must
be paid somewhere to make sure the memremap() mapping is still valid.
Sorry for being so slow, is what I asked. what is exactly pmem unbind ?
Currently in
On 08/13/2015 05:37 PM, Christoph Hellwig wrote:
Hi Boaz,
can you please fix your quoting? I read down about 10 pages but still
couldn't find a comment from you. For now I gave up on this mail.
Sorry here:
+void *kmap_atomic_pfn_t(__pfn_t pfn)
+{
+ struct page *page =
On 08/13/2015 05:41 PM, Christoph Hellwig wrote:
On Thu, Aug 13, 2015 at 04:23:38PM +0300, Boaz Harrosh wrote:
DAX as is is races against pmem unbind. A synchronization cost must
be paid somewhere to make sure the memremap() mapping is still valid.
Sorry for being so slow, is what I asked.
On 08/13/2015 05:48 PM, Boaz Harrosh wrote:
There is already an object that holds a relationship of physical
to Kernel-virtual. It is called a memory-section. Why not just
widen its definition?
BTW: Regarding the widen its definition
I was thinking of two possible new models here:
[1-A
On Wed, Aug 12, 2015 at 11:01:09PM -0400, Dan Williams wrote:
+static inline __pfn_t page_to_pfn_t(struct page *page)
+{
+ __pfn_t pfn = { .val = page_to_pfn(page) PAGE_SHIFT, };
+
+ return pfn;
+}
static inline __pfn_t page_to_pfn_t(struct page *page)
{
__pfn_t __pfn;
On Thu, Aug 13, 2015 at 10:35 AM, Matthew Wilcox wi...@linux.intel.com wrote:
On Wed, Aug 12, 2015 at 11:01:09PM -0400, Dan Williams wrote:
+static inline __pfn_t page_to_pfn_t(struct page *page)
+{
+ __pfn_t pfn = { .val = page_to_pfn(page) PAGE_SHIFT, };
+
+ return pfn;
+}
On 08/13/2015 07:48 AM, Boaz Harrosh wrote:
There is already an object that holds a relationship of physical
to Kernel-virtual. It is called a memory-section. Why not just
widen its definition?
Memory sections are purely there to map physical address ranges back to
metadata about them.
On 08/13/2015 06:01 AM, Dan Williams wrote:
> Introduce a type that encapsulates a page-frame-number that can also be
> used to encode other information. This other information is the
> traditional "page_link" encoding in a scatterlist, but can also denote
> "device memory". Where "device
Introduce a type that encapsulates a page-frame-number that can also be
used to encode other information. This other information is the
traditional "page_link" encoding in a scatterlist, but can also denote
"device memory". Where "device memory" is a set of pfns that are not
part of the kernel's
On 08/13/2015 06:01 AM, Dan Williams wrote:
Introduce a type that encapsulates a page-frame-number that can also be
used to encode other information. This other information is the
traditional page_link encoding in a scatterlist, but can also denote
device memory. Where device memory is a set
Introduce a type that encapsulates a page-frame-number that can also be
used to encode other information. This other information is the
traditional page_link encoding in a scatterlist, but can also denote
device memory. Where device memory is a set of pfns that are not
part of the kernel's
24 matches
Mail list logo
