On 04/17/2018 02:31 PM, Sinan Kaya wrote: > On 4/17/2018 5:21 PM, Dave Jiang wrote: >>> Given we have few users of DMA Engine, I believe we should try to keep as >>> much functionality as possible in the kernel to allow new features to be >>> developed rather than limiting people's choices. >>> >> Would love to see more in kernel consumers for dmaengine. Maybe things >> that help accelerate core kernel bits? :) >> > > Side conversation... > > I'm on the same boat. I have been thinking about this for some time. > I also know that Intel maintains a repo in sourceforge for experimental > work that was never upstreamed. > > What kind of things could be useful for DMA engine optimization? 1. async_tx removal because it's kind of broken. 2. channel hotplug in case future hardware has virtual channels instead of physical fixed? 3. device hotplug? idk 4. maybe instead of having a giant group of dmaengine ops, we move it towards a single API call and pass in command context? Perhaps a resemblance to blk-mq type of structures? That way, every time we have a new op, we don't need to add yet another function pointer. We also have a source SG and a destination SG. That way it should cover virtual or DMA memory right? I wonder how it would work for RAID operations though.... Just random ideas I'm throwing out there. > > I was told that most of the kernel data structures are resident and cannot > be paged but then I hear about kernel virtual memory allocated by vmalloc > that it makes me nervous. > > What worked until now and what failed? That was the series. After doing some testing, we didn't see the performance we wanted with IOATDMA so we decided to put that on hold for now. https://lists.01.org/pipermail/linux-nvdimm/2017-August/011962.html > > I understand that pinning pages is the biggest challenge. What else? > Given that some of the qcom DMA engines can do virtual memory, that means you won't have to worry about pinning pages? Do the DMA engines do page faulting for you with the virtual address? That would make pinning pages a non-issue no? -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
