From: Huaisheng Ye <[email protected]>
Some functions within fs/dax and dax/super don't need to get kaddr from
direct_access. Assigning NULL to kaddr to ->direct_access() is more
straightforward and simple than offering a useless local pointer.
So all direct_access() need to check the validity of second rank pointer
kaddr for NULL assignment. If kaddr equals to NULL, it doesn't need to
calculate its value.
* This series are supplement to [PATCH v2 00/14]mm: Asynchronous +
multithreaded memmap init for ZONE_DEVICE. [1]
[1]: https://lkml.org/lkml/2018/7/16/828
Huaisheng Ye (5):
libnvdimm, pmem: Allow a NULL-kaddr to ->direct_access()
tools/testing/nvdimm: Allow a NULL-kaddr to ->direct_access()
s390, dcssblk: Allow a NULL-kaddr to ->direct_access()
filesystem-dax: Do not request a pointer kaddr when not required
dax/super: Do not request a pointer kaddr when not required
drivers/dax/super.c | 3 +--
drivers/nvdimm/pmem.c | 4 +++-
drivers/s390/block/dcssblk.c | 3 ++-
fs/dax.c | 3 +--
tools/testing/nvdimm/pmem-dax.c | 6 ++++--
5 files changed, 11 insertions(+), 8 deletions(-)
--
1.8.3.1
From: Huaisheng Ye <[email protected]>
pmem_direct_access() needs to check the validity of second rank
pointer kaddr for NULL assignment. If kaddr equals to NULL, it
doesn't need to calculate the value.
Signed-off-by: Huaisheng Ye <[email protected]>
---
drivers/nvdimm/pmem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 9d71492..b1d121a 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -232,7 +232,9 @@ __weak long __pmem_direct_access(struct pmem_device *pmem, pgoff_t pgoff,
if (unlikely(is_bad_pmem(&pmem->bb, PFN_PHYS(pgoff) / 512,
PFN_PHYS(nr_pages))))
return -EIO;
- *kaddr = pmem->virt_addr + offset;
+
+ if (kaddr)
+ *kaddr = pmem->virt_addr + offset;
*pfn = phys_to_pfn_t(pmem->phys_addr + offset, pmem->pfn_flags);
/*
--
1.8.3.1
From: Huaisheng Ye <[email protected]>
The mock / test version of pmem_direct_access() needs to check the
validity of second rank pointer kaddr for NULL assignment. If kaddr
equals to NULL, it doesn't need to calculate the value.
Signed-off-by: Huaisheng Ye <[email protected]>
---
tools/testing/nvdimm/pmem-dax.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/testing/nvdimm/pmem-dax.c b/tools/testing/nvdimm/pmem-dax.c
index b53596a..c3ba159 100644
--- a/tools/testing/nvdimm/pmem-dax.c
+++ b/tools/testing/nvdimm/pmem-dax.c
@@ -31,7 +31,8 @@ long __pmem_direct_access(struct pmem_device *pmem, pgoff_t pgoff,
if (get_nfit_res(pmem->phys_addr + offset)) {
struct page *page;
- *kaddr = pmem->virt_addr + offset;
+ if (kaddr)
+ *kaddr = pmem->virt_addr + offset;
page = vmalloc_to_page(pmem->virt_addr + offset);
*pfn = page_to_pfn_t(page);
pr_debug_ratelimited("%s: pmem: %p pgoff: %#lx pfn: %#lx\n",
@@ -40,7 +41,8 @@ long __pmem_direct_access(struct pmem_device *pmem, pgoff_t pgoff,
return 1;
}
- *kaddr = pmem->virt_addr + offset;
+ if (kaddr)
+ *kaddr = pmem->virt_addr + offset;
*pfn = phys_to_pfn_t(pmem->phys_addr + offset, pmem->pfn_flags);
/*
--
1.8.3.1
From: Huaisheng Ye <[email protected]>
dcssblk_direct_access() needs to check the validity of second rank
pointer kaddr for NULL assignment. If kaddr equals to NULL, it
doesn't need to calculate the value.
Signed-off-by: Huaisheng Ye <[email protected]>
---
drivers/s390/block/dcssblk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c
index 0a312e4..9c13dc5 100644
--- a/drivers/s390/block/dcssblk.c
+++ b/drivers/s390/block/dcssblk.c
@@ -915,7 +915,8 @@ static DEVICE_ATTR(save, S_IWUSR | S_IRUSR, dcssblk_save_show,
unsigned long dev_sz;
dev_sz = dev_info->end - dev_info->start + 1;
- *kaddr = (void *) dev_info->start + offset;
+ if (kaddr)
+ *kaddr = (void *) dev_info->start + offset;
*pfn = __pfn_to_pfn_t(PFN_DOWN(dev_info->start + offset),
PFN_DEV|PFN_SPECIAL);
--
1.8.3.1
From: Huaisheng Ye <[email protected]>
Some functions within fs/dax don't need to get pointer kaddr from
direct_access. In support of allowing memmap initialization to run
in the background elide requests for pointer kaddr when not required.
Signed-off-by: Huaisheng Ye <[email protected]>
---
fs/dax.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index aaec72de..abdb9e2 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -870,7 +870,6 @@ static int dax_iomap_pfn(struct iomap *iomap, loff_t pos, size_t size,
{
const sector_t sector = dax_iomap_sector(iomap, pos);
pgoff_t pgoff;
- void *kaddr;
int id, rc;
long length;
@@ -879,7 +878,7 @@ static int dax_iomap_pfn(struct iomap *iomap, loff_t pos, size_t size,
return rc;
id = dax_read_lock();
length = dax_direct_access(iomap->dax_dev, pgoff, PHYS_PFN(size),
- &kaddr, pfnp);
+ NULL, pfnp);
if (length < 0) {
rc = length;
goto out;
--
1.8.3.1
From: Huaisheng Ye <[email protected]>
Some functions within driver/dax don't need to get pointer kaddr from
direct_access. In support of allowing memmap initialization to run in
the background elide requests for pointer kaddr when not required.
Signed-off-by: Huaisheng Ye <[email protected]>
---
drivers/dax/super.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index 2b2332b..fad68d2 100644
--- a/drivers/dax/super.c
+++ b/drivers/dax/super.c
@@ -88,7 +88,6 @@ int __bdev_dax_supported(struct super_block *sb, int blocksize)
struct dax_device *dax_dev;
pgoff_t pgoff;
int err, id;
- void *kaddr;
pfn_t pfn;
long len;
@@ -113,7 +112,7 @@ int __bdev_dax_supported(struct super_block *sb, int blocksize)
}
id = dax_read_lock();
- len = dax_direct_access(dax_dev, pgoff, 1, &kaddr, &pfn);
+ len = dax_direct_access(dax_dev, pgoff, 1, NULL, &pfn);
dax_read_unlock(id);
put_dax(dax_dev);
--
1.8.3.1
On 07/24/2018 10:45 AM, Huaisheng Ye wrote:
> From: Huaisheng Ye <[email protected]>
>
> dcssblk_direct_access() needs to check the validity of second rank
> pointer kaddr for NULL assignment. If kaddr equals to NULL, it
> doesn't need to calculate the value.
>
> Signed-off-by: Huaisheng Ye <[email protected]>
> ---
> drivers/s390/block/dcssblk.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c
> index 0a312e4..9c13dc5 100644
> --- a/drivers/s390/block/dcssblk.c
> +++ b/drivers/s390/block/dcssblk.c
> @@ -915,7 +915,8 @@ static DEVICE_ATTR(save, S_IWUSR | S_IRUSR, dcssblk_save_show,
> unsigned long dev_sz;
>
> dev_sz = dev_info->end - dev_info->start + 1;
> - *kaddr = (void *) dev_info->start + offset;
> + if (kaddr)
> + *kaddr = (void *) dev_info->start + offset;
So you are trading of a load + add (dev_info->start should be cache hot) against a
compare+branch . Not sure that this is always a win.
> *pfn = __pfn_to_pfn_t(PFN_DOWN(dev_info->start + offset),
> PFN_DEV|PFN_SPECIAL);
>
>
From: Christian Borntraeger <[email protected]>
Sent: Tuesday, July 24, 2018 4:54 PM
> On 07/24/2018 10:45 AM, Huaisheng Ye wrote:
> > From: Huaisheng Ye <[email protected]>
> >
> > dcssblk_direct_access() needs to check the validity of second rank
> > pointer kaddr for NULL assignment. If kaddr equals to NULL, it
> > doesn't need to calculate the value.
> >
> > Signed-off-by: Huaisheng Ye <[email protected]>
> > ---
> > drivers/s390/block/dcssblk.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c
> > index 0a312e4..9c13dc5 100644
> > --- a/drivers/s390/block/dcssblk.c
> > +++ b/drivers/s390/block/dcssblk.c
> > @@ -915,7 +915,8 @@ static DEVICE_ATTR(save, S_IWUSR | S_IRUSR, dcssblk_save_show,
> > unsigned long dev_sz;
> >
> > dev_sz = dev_info->end - dev_info->start + 1;
> > - *kaddr = (void *) dev_info->start + offset;
> > + if (kaddr)
> > + *kaddr = (void *) dev_info->start + offset;
>
> So you are trading of a load + add (dev_info->start should be cache hot) against a
> compare+branch . Not sure that this is always a win.
Hmm...the calculation process of pfn is more complicated than kaddr. I think you agree to check pfn but not sure kaddr, right?
From the logical consistency of code, I think it shall be better to give pfn and kaddr similar treatment.
Cheers,
Huaisheng Ye
On 07/24/2018 11:46 AM, Huaisheng HS1 Ye wrote:
> From: Christian Borntraeger <[email protected]>
> Sent: Tuesday, July 24, 2018 4:54 PM
>> On 07/24/2018 10:45 AM, Huaisheng Ye wrote:
>>> From: Huaisheng Ye <[email protected]>
>>>
>>> dcssblk_direct_access() needs to check the validity of second rank
>>> pointer kaddr for NULL assignment. If kaddr equals to NULL, it
>>> doesn't need to calculate the value.
>>>
>>> Signed-off-by: Huaisheng Ye <[email protected]>
>>> ---
>>> drivers/s390/block/dcssblk.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c
>>> index 0a312e4..9c13dc5 100644
>>> --- a/drivers/s390/block/dcssblk.c
>>> +++ b/drivers/s390/block/dcssblk.c
>>> @@ -915,7 +915,8 @@ static DEVICE_ATTR(save, S_IWUSR | S_IRUSR, dcssblk_save_show,
>>> unsigned long dev_sz;
>>>
>>> dev_sz = dev_info->end - dev_info->start + 1;
>>> - *kaddr = (void *) dev_info->start + offset;
>>> + if (kaddr)
>>> + *kaddr = (void *) dev_info->start + offset;
>>
>> So you are trading of a load + add (dev_info->start should be cache hot) against a
>> compare+branch . Not sure that this is always a win.
>
> Hmm...the calculation process of pfn is more complicated than kaddr. I think you agree to check pfn but not sure kaddr, right?
> From the logical consistency of code, I think it shall be better to give pfn and kaddr similar treatment.
Reading it again, its more that I do not like the patch description. It reads
like an optimization, (and I think it is not) but it should rather read more
like "with an upcoming change kaddr can be NULL" or so.
From: Christian Borntraeger <[email protected]>
Sent: Tuesday, July 24, 2018 7:16 PM
> >> So you are trading of a load + add (dev_info->start should be cache hot) against a
> >> compare+branch . Not sure that this is always a win.
> >
> > Hmm...the calculation process of pfn is more complicated than kaddr. I think you agree to
> check pfn but not sure kaddr, right?
> > From the logical consistency of code, I think it shall be better to give pfn and kaddr similar
> treatment.
>
> Reading it again, its more that I do not like the patch description. It reads
> like an optimization, (and I think it is not) but it should rather read more
> like "with an upcoming change kaddr can be NULL" or so.
Thanks for suggestion, I will reword the patch description during next submission.
Does the patch itself need to be modified? If has, any suggestion is welcome.
Cheers,
Huaisheng Ye
On Tue, Jul 24, 2018 at 04:45:05PM +0800, Huaisheng Ye wrote:
> From: Huaisheng Ye <[email protected]>
>
> Some functions within fs/dax and dax/super don't need to get kaddr from
> direct_access. Assigning NULL to kaddr to ->direct_access() is more
> straightforward and simple than offering a useless local pointer.
>
> So all direct_access() need to check the validity of second rank pointer
> kaddr for NULL assignment. If kaddr equals to NULL, it doesn't need to
> calculate its value.
>
> * This series are supplement to [PATCH v2 00/14]mm: Asynchronous +
> multithreaded memmap init for ZONE_DEVICE. [1]
>
> [1]: https://lkml.org/lkml/2018/7/16/828
This whole series looks good to me. Just a few comments:
1) Does this series actually depend on the "Asynchronous multithreaded mmap
init for ZONE_DEVICE" series from Dan? It seems totally independent to me?
I reviewed yours by applying to linux/master, which worked fine. I ask
because Dan's series has been delayed to after v4.19, and if yours isn't
actually dependent it could possibly go in sooner.
2) I agree with Christian's comment that the changelogs could be improved
slightly. Remember that the goal of the changelog isn't to describe *what*
the code is doing, but *why*. We can read that the code now checks if 'kaddr'
is NULL, and if so we don't calculate it. It's useful to say that callers may
have no need for 'kaddr', so this patch is prep for allowing them to pass in
NULL instead of having to pass in a pointer that they then just throw away.
3) I think you should make one more change to kill the unused 'dummy_addr'
variable in persistent_memory_claim(). That was the one last case of a dummy
'kaddr' type variable that I could find.
From: Ross Zwisler <[email protected]>
Sent: Tuesday, July 24, 2018 10:50 PM
> > Some functions within fs/dax and dax/super don't need to get kaddr from
> > direct_access. Assigning NULL to kaddr to ->direct_access() is more
> > straightforward and simple than offering a useless local pointer.
> >
> > So all direct_access() need to check the validity of second rank pointer
> > kaddr for NULL assignment. If kaddr equals to NULL, it doesn't need to
> > calculate its value.
> >
> > * This series are supplement to [PATCH v2 00/14]mm: Asynchronous +
> > multithreaded memmap init for ZONE_DEVICE. [1]
> >
> > [1]: https://lkml.org/lkml/2018/7/16/828
>
> This whole series looks good to me. Just a few comments:
>
> 1) Does this series actually depend on the "Asynchronous multithreaded mmap
> init for ZONE_DEVICE" series from Dan? It seems totally independent to me?
> I reviewed yours by applying to linux/master, which worked fine. I ask
> because Dan's series has been delayed to after v4.19, and if yours isn't
> actually dependent it could possibly go in sooner.
This series doesn't depend on Dan's 'Asynchronous multithreaded mmap init
for ZONE_DEVICE'. For the part as pfn, which overlaps Dan's original series.
Because I post them earlier than Dan's, Dan generously dropped the overlapping
from his series and adopted mine to the series of 'Asynchronous multithreaded'.
It is very thankful.
I knew Dan's series would be delayed, I can resend the series, both kaddr and pfn,
for faster merging to mainline.
> 2) I agree with Christian's comment that the changelogs could be improved
> slightly. Remember that the goal of the changelog isn't to describe *what*
> the code is doing, but *why*. We can read that the code now checks if 'kaddr'
> is NULL, and if so we don't calculate it. It's useful to say that callers may
> have no need for 'kaddr', so this patch is prep for allowing them to pass in
> NULL instead of having to pass in a pointer that they then just throw away.
Thanks for advice. I will follow your suggestion during next submission.
> 3) I think you should make one more change to kill the unused 'dummy_addr'
> variable in persistent_memory_claim(). That was the one last case of a dummy
> 'kaddr' type variable that I could find.
Yes, you are right. I haven't updated my code base to latest mainline, so couldn't
notice it. It seems there is a new created file here as dm-writecache.c.
Thanks for hints.
Cheers,
Huaisheng Ye