On 2/5/19 5:38 AM, Tom Talpey wrote:
>
> Ok, I'm satisfied the four-9's latency spike is in not your code. :-)
> Results look good relative to baseline. Thanks for doublechecking!
>
> Tom.
Great, in that case, I'll put the new before-and-after results in the next
version. Appreciate your help
On Mon, 4 Feb 2019, Ira Weiny wrote:
> On Mon, Feb 04, 2019 at 05:14:19PM +, Christopher Lameter wrote:
> > Frankly I still think this does not solve anything.
> >
> > Concurrent write access from two sources to a single page is simply wrong.
> > You cannot make this right by allowing long ter
On 2/5/2019 3:22 AM, John Hubbard wrote:
On 2/4/19 5:41 PM, Tom Talpey wrote:
On 2/4/2019 12:21 AM, john.hubb...@gmail.com wrote:
From: John Hubbard
Performance: here is an fio run on an NVMe drive, using this for the fio
configuration file:
[reader]
direct=1
ioengine=libaio
On 2/4/19 5:41 PM, Tom Talpey wrote:
On 2/4/2019 12:21 AM, john.hubb...@gmail.com wrote:
From: John Hubbard
Performance: here is an fio run on an NVMe drive, using this for the fio
configuration file:
[reader]
direct=1
ioengine=libaio
blocksize=4096
size=1g
numj
On 2/4/2019 12:21 AM, john.hubb...@gmail.com wrote:
From: John Hubbard
Performance: here is an fio run on an NVMe drive, using this for the fio
configuration file:
[reader]
direct=1
ioengine=libaio
blocksize=4096
size=1g
numjobs=1
rw=read
iodepth=64
re
On Mon, Feb 04, 2019 at 05:14:19PM +, Christopher Lameter wrote:
> Frankly I still think this does not solve anything.
>
> Concurrent write access from two sources to a single page is simply wrong.
> You cannot make this right by allowing long term RDMA pins in a filesystem
> and thus the file
On Mon, Feb 04, 2019 at 06:21:39PM +, Christopher Lameter wrote:
> On Mon, 4 Feb 2019, Jason Gunthorpe wrote:
>
> > On Mon, Feb 04, 2019 at 05:14:19PM +, Christopher Lameter wrote:
> > > Frankly I still think this does not solve anything.
> > >
> > > Concurrent write access from two source
On Mon, 4 Feb 2019, Jason Gunthorpe wrote:
> On Mon, Feb 04, 2019 at 05:14:19PM +, Christopher Lameter wrote:
> > Frankly I still think this does not solve anything.
> >
> > Concurrent write access from two sources to a single page is simply wrong.
> > You cannot make this right by allowing lo
On Mon, Feb 04, 2019 at 05:14:19PM +, Christopher Lameter wrote:
> Frankly I still think this does not solve anything.
>
> Concurrent write access from two sources to a single page is simply wrong.
> You cannot make this right by allowing long term RDMA pins in a filesystem
> and thus the file
Frankly I still think this does not solve anything.
Concurrent write access from two sources to a single page is simply wrong.
You cannot make this right by allowing long term RDMA pins in a filesystem
and thus the filesystem can never update part of its files on disk.
Can we just disable RDMA to
On Mon, 4 Feb 2019, Christoph Hellwig wrote:
> On Mon, Feb 04, 2019 at 04:08:02PM +, Christopher Lameter wrote:
> > It may be worth noting a couple of times in this text that this was
> > designed for anonymous memory and that such use is/was ok. We are talking
> > about a use case here using
On Mon, Feb 04, 2019 at 04:08:02PM +, Christopher Lameter wrote:
> It may be worth noting a couple of times in this text that this was
> designed for anonymous memory and that such use is/was ok. We are talking
> about a use case here using mmapped access with a regular filesystem that
> was no
On Sun, 3 Feb 2019, john.hubb...@gmail.com wrote:
> Some kernel components (file systems, device drivers) need to access
> memory that is specified via process virtual address. For a long time, the
> API to achieve that was get_user_pages ("GUP") and its variations. However,
> GUP has critical lim
From: John Hubbard
Hi,
I'm calling this RFC v2, even though with all the discussion it actually
feels
like about v7 or so. But now that the dust has settled, it's time to show a
surprisingly small, cleaner approach. Jan and Jerome came up with a scheme
(discussed in more detail in "track gup-pin
14 matches
Mail list logo
