[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <658363f418a6585a1ffc0038b86c8e95487e8130.camel@redhat.com>
Date: Wed, 06 Feb 2019 21:42:03 -0500
From: Doug Ledford <dledford@...hat.com>
To: Dan Williams <dan.j.williams@...el.com>
Cc: Jason Gunthorpe <jgg@...pe.ca>, Dave Chinner <david@...morbit.com>,
Christopher Lameter <cl@...ux.com>,
Matthew Wilcox <willy@...radead.org>, Jan Kara <jack@...e.cz>,
Ira Weiny <ira.weiny@...el.com>,
lsf-pc@...ts.linux-foundation.org,
linux-rdma <linux-rdma@...r.kernel.org>,
Linux MM <linux-mm@...ck.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
John Hubbard <jhubbard@...dia.com>,
Jerome Glisse <jglisse@...hat.com>,
Michal Hocko <mhocko@...nel.org>
Subject: Re: [LSF/MM TOPIC] Discuss least bad options for resolving
longterm-GUP usage by RDMA
On Wed, 2019-02-06 at 14:44 -0800, Dan Williams wrote:
> On Wed, Feb 6, 2019 at 2:25 PM Doug Ledford <dledford@...hat.com> 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?
--
Doug Ledford <dledford@...hat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists