On Wed, Feb 6, 2019 at 6:42 PM Doug Ledford <dledford@xxxxxxxxxx> wrote: > > On Wed, 2019-02-06 at 14:44 -0800, Dan Williams wrote: > > On Wed, Feb 6, 2019 at 2:25 PM Doug Ledford <dledford@xxxxxxxxxx> wrote: > > > Can someone give me a real world scenario that someone is *actually* > > > asking for with this? > > > > I'll point to this example. At the 6:35 mark Kodi talks about the > > Oracle use case for DAX + RDMA. > > > > https://youtu.be/ywKPPIE8JfQ?t=395 > > I watched this, and I see that Oracle is all sorts of excited that their > storage machines can scale out, and they can access the storage and it > has basically no CPU load on the storage server while performing > millions of queries. What I didn't hear in there is why DAX has to be > in the picture, or why Oracle couldn't do the same thing with a simple > memory region exported directly to the RDMA subsystem, or why reflink or > any of the other features you talk about are needed. So, while these > things may legitimately be needed, this video did not tell me about > how/why they are needed, just that RDMA is really, *really* cool for > their use case and gets them 0% CPU utilization on their storage > servers. I didn't watch the whole thing though. Do they get into that > later on? Do they get to that level of technical discussion, or is this > all higher level? They don't. The point of sharing that video was illustrating that RDMA to persistent memory use case. That 0% cpu utilization is because the RDMA target is not page-cache / anonymous on the storage box it's directly to a file offset in DAX / persistent memory. A solution to truncate lets that use case use more than just Device-DAX or ODP capable adapters. That said, I need to let Ira jump in here because saying layout leases solves the problem is not true, it's just the start of potentially solving the problem. It's not clear to me what the long tail of work looks like once the filesystem raises a notification to the RDMA target process.
