> On Feb 28, 2018, at 2:12 AM, Pavel Emelyanov wrote:
>
> On 02/27/2018 05:18 AM, Dmitry V. Levin wrote:
>> On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote:
>>> On 02/21/2018 03:44 AM, Andrew Morton wrote:
On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport
> On Feb 28, 2018, at 2:12 AM, Pavel Emelyanov wrote:
>
> On 02/27/2018 05:18 AM, Dmitry V. Levin wrote:
>> On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote:
>>> On 02/21/2018 03:44 AM, Andrew Morton wrote:
On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport
wrote:
On Wed, Feb 28, 2018 at 10:12:55AM +0300, Pavel Emelyanov wrote:
> On 02/27/2018 05:18 AM, Dmitry V. Levin wrote:
> > On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote:
> >> On 02/21/2018 03:44 AM, Andrew Morton wrote:
> >>> On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport
> >>>
On Wed, Feb 28, 2018 at 10:12:55AM +0300, Pavel Emelyanov wrote:
> On 02/27/2018 05:18 AM, Dmitry V. Levin wrote:
> > On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote:
> >> On 02/21/2018 03:44 AM, Andrew Morton wrote:
> >>> On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport
> >>>
On 02/27/2018 05:18 AM, Dmitry V. Levin wrote:
> On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote:
>> On 02/21/2018 03:44 AM, Andrew Morton wrote:
>>> On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport
>>> wrote:
>>>
This patches introduces new
On 02/27/2018 05:18 AM, Dmitry V. Levin wrote:
> On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote:
>> On 02/21/2018 03:44 AM, Andrew Morton wrote:
>>> On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport
>>> wrote:
>>>
This patches introduces new process_vmsplice system call that
On Tue, Feb 27, 2018 at 05:18:18AM +0300, Dmitry V. Levin wrote:
> On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote:
> > On 02/21/2018 03:44 AM, Andrew Morton wrote:
> > > On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport
> > > wrote:
> > >
> > >> This
On Tue, Feb 27, 2018 at 05:18:18AM +0300, Dmitry V. Levin wrote:
> On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote:
> > On 02/21/2018 03:44 AM, Andrew Morton wrote:
> > > On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport
> > > wrote:
> > >
> > >> This patches introduces new
On Mon, Feb 26, 2018 at 09:38:19AM -0700, Nathan Hjelm wrote:
> All MPI implementations have support for using CMA to transfer data
> between local processes. The performance is fairly good (not as good as
> XPMEM) but the interface limits what we can do with to remote process
> memory (no
On Mon, Feb 26, 2018 at 09:38:19AM -0700, Nathan Hjelm wrote:
> All MPI implementations have support for using CMA to transfer data
> between local processes. The performance is fairly good (not as good as
> XPMEM) but the interface limits what we can do with to remote process
> memory (no
On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote:
> On 02/21/2018 03:44 AM, Andrew Morton wrote:
> > On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport
> > wrote:
> >
> >> This patches introduces new process_vmsplice system call that combines
> >>
On Mon, Feb 26, 2018 at 12:02:25PM +0300, Pavel Emelyanov wrote:
> On 02/21/2018 03:44 AM, Andrew Morton wrote:
> > On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport
> > wrote:
> >
> >> This patches introduces new process_vmsplice system call that combines
> >> functionality of process_vm_read
All MPI implementations have support for using CMA to transfer data between
local processes. The performance is fairly good (not as good as XPMEM) but the
interface limits what we can do with to remote process memory (no atomics). I
have not heard about this new proposal. What is the benefit of
All MPI implementations have support for using CMA to transfer data between
local processes. The performance is fairly good (not as good as XPMEM) but the
interface limits what we can do with to remote process memory (no atomics). I
have not heard about this new proposal. What is the benefit of
On 02/21/2018 03:44 AM, Andrew Morton wrote:
> On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport
> wrote:
>
>> This patches introduces new process_vmsplice system call that combines
>> functionality of process_vm_read and vmsplice.
>
> All seems fairly strightforward.
On 02/21/2018 03:44 AM, Andrew Morton wrote:
> On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport
> wrote:
>
>> This patches introduces new process_vmsplice system call that combines
>> functionality of process_vm_read and vmsplice.
>
> All seems fairly strightforward. The big question is: do
On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport
wrote:
> This patches introduces new process_vmsplice system call that combines
> functionality of process_vm_read and vmsplice.
All seems fairly strightforward. The big question is: do we know that
people will actually
On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport
wrote:
> This patches introduces new process_vmsplice system call that combines
> functionality of process_vm_read and vmsplice.
All seems fairly strightforward. The big question is: do we know that
people will actually use this, and get
Hi,
This patches introduces new process_vmsplice system call that combines
functionality of process_vm_read and vmsplice.
It allows to map the memory of another process into a pipe, similarly to
what vmsplice does for its own address space.
The patch 2/4 ("vm: add a syscall to map a process
Hi,
This patches introduces new process_vmsplice system call that combines
functionality of process_vm_read and vmsplice.
It allows to map the memory of another process into a pipe, similarly to
what vmsplice does for its own address space.
The patch 2/4 ("vm: add a syscall to map a process
20 matches
Mail list logo