This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe
- From: Pavel Emelyanov <xemul at virtuozzo dot com>
- To: Andrew Morton <akpm at linux-foundation dot org>, Mike Rapoport <rppt at linux dot vnet dot ibm dot com>
- Cc: Alexander Viro <viro at zeniv dot linux dot org dot uk>, linux-mm at kvack dot org, linux-fsdevel at vger dot kernel dot org, linux-kernel at vger dot kernel dot org, linux-api at vger dot kernel dot org, criu at openvz dot org, gdb at sourceware dot org, devel at lists dot open-mpi dot org, rr-dev at mozilla dot org, Arnd Bergmann <arnd at arndb dot de>, Michael Kerrisk <mtk dot manpages at gmail dot com>, Thomas Gleixner <tglx at linutronix dot de>, Josh Triplett <josh at joshtriplett dot org>, Jann Horn <jannh at google dot com>, Greg KH <gregkh at linuxfoundation dot org>, Andrei Vagin <avagin at openvz dot org>
- Date: Mon, 26 Feb 2018 12:02:25 +0300
- Subject: Re: [PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=xemul at virtuozzo dot com;
- References: <1515479453-14672-1-git-send-email-rppt@linux.vnet.ibm.com> <20180220164406.3ec34509376f16841dc66e34@linux-foundation.org>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 02/21/2018 03:44 AM, Andrew Morton wrote:
> On Tue, 9 Jan 2018 08:30:49 +0200 Mike Rapoport <rppt@linux.vnet.ibm.com> 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 sufficient value from it to
> justify its addition?
Yes, that's what bothers us a lot too :) I've tried to start with finding out if anyone
used the sys_read/write_process_vm() calls, but failed :( Does anybody know how popular
these syscalls are? If its users operate on big amount of memory, they could benefit from
the proposed splice extension.
-- Pavel