3:37 a.m.
Hi Dave
I hope you are well. Logan and I were looking at adding DMA support to PMEM and then were
informed you have proposed some patches to do just that for the ioat DMA engine. The
latest version of those I can see were the v7 from August 2017. Is there a more recent
version? What happened to that series?
https://lists.01.org/pipermail/linux-nvdimm/2017-August/012208.html
Cheers
Stephen
3:52 a.m.
On 08/21/2018 10:37 AM, Stephen Bates wrote:
Hi Dave
I hope you are well. Logan and I were looking at adding DMA support to PMEM and then were
informed you have proposed some patches to do just that for the ioat DMA engine. The
latest version of those I can see were the v7 from August 2017. Is there a more recent
version? What happened to that series?
https://lists.01.org/pipermail/linux-nvdimm/2017-August/012208.html
Cheers
Stephen
Hi Guys. Nothing has happened...yet... It's just on hold for now.
Here's where I left it last
https://git.kernel.org/pub/scm/linux/kernel/git/djiang/linux.git/log/?h=p...
I do think we need to do some rework with the dmaengine in order to get
better efficiency as well. At some point I would like to see a call in
dmaengine that will take a request (similar to mq) and just operate on
that and submit the descriptors in a single call. I think that can
possibly deprecate all the host of function pointers for dmaengine. I'm
hoping to find some time to take a look at some of this work towards the
end of the year. But I'd be highly interested if you guys have ideas and
thoughts on this topic. And you are welcome to take my patches and run
with it.
4:07 a.m.
Here's where I left it last
https://git.kernel.org/pub/scm/linux/kernel/git/djiang/linux.git/log/?h=p...
Thanks Dave. I'll certainly rebase these on 4.18.x and do some testing!
I do think we need to do some rework with the dmaengine in order to
get
better efficiency as well. At some point I would like to see a call in
dmaengine that will take a request (similar to mq) and just operate on
that and submit the descriptors in a single call. I think that can
possibly deprecate all the host of function pointers for dmaengine. I'm
hoping to find some time to take a look at some of this work towards the
end of the year. But I'd be highly interested if you guys have ideas and
thoughts on this topic. And you are welcome to take my patches and run
with it.
OK, we were experimenting with a single PMEM driver and making decisions on DMA vs memcpy
based on IO size rather than forcing the user to choose which driver to use.
Stephen
4:11 a.m.
On 08/21/2018 11:07 AM, Stephen Bates wrote:
> Here's where I left it last
>
https://git.kernel.org/pub/scm/linux/kernel/git/djiang/linux.git/log/?h=p...
Thanks Dave. I'll certainly rebase these on 4.18.x and do some testing!
> I do think we need to do some rework with the dmaengine in order to get
> better efficiency as well. At some point I would like to see a call in
> dmaengine that will take a request (similar to mq) and just operate on
> that and submit the descriptors in a single call. I think that can
> possibly deprecate all the host of function pointers for dmaengine. I'm
> hoping to find some time to take a look at some of this work towards the
> end of the year. But I'd be highly interested if you guys have ideas and
> thoughts on this topic. And you are welcome to take my patches and run
> with it.
OK, we were experimenting with a single PMEM driver and making decisions on DMA vs memcpy
based on IO size rather than forcing the user to choose which driver to use.
Oh yeah. Also I think what we discovered is that the block layer will
not send anything larger than 4k buffers in SGs. So unless your DMA
engine is very efficient with processing 4k you don't get great
performance. Not sure how to get around that since existing DMA engines
tend to prefer larger buffers to get better performance.
Stephen
4:13 a.m.
On 21/08/18 12:11 PM, Dave Jiang wrote:
On 08/21/2018 11:07 AM, Stephen Bates wrote:
>> Here's where I left it last
>>
https://git.kernel.org/pub/scm/linux/kernel/git/djiang/linux.git/log/?h=p...
>
> Thanks Dave. I'll certainly rebase these on 4.18.x and do some testing!
>
>> I do think we need to do some rework with the dmaengine in order to get
>> better efficiency as well. At some point I would like to see a call in
> > dmaengine that will take a request (similar to mq) and just operate on
> > that and submit the descriptors in a single call. I think that can
> > possibly deprecate all the host of function pointers for dmaengine. I'm
> > hoping to find some time to take a look at some of this work towards the
> > end of the year. But I'd be highly interested if you guys have ideas and
> > thoughts on this topic. And you are welcome to take my patches and run
> > with it.
>
> OK, we were experimenting with a single PMEM driver and making decisions on DMA vs
memcpy based on IO size rather than forcing the user to choose which driver to use.
Oh yeah. Also I think what we discovered is that the block layer will
not send anything larger than 4k buffers in SGs. So unless your DMA
engine is very efficient with processing 4k you don't get great
performance. Not sure how to get around that since existing DMA engines
tend to prefer larger buffers to get better performance.
Yeah, that's exactly what we were running up against. Then we found your
patch set that pretty much dealt with a lot of the problems we were seeing.
From a code perspective, I like the split modules, but I guess it puts
a
burden on the user to blacklist one or the other to get DMA or not.
Which may depend on work load.
Logan
1489
days inactive
1489
days old
4 comments
3 participants
participants (3)
-
Dave Jiang -
Logan Gunthorpe -
Stephen Bates