From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64676 invoked by alias); 27 Feb 2018 07:10:34 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 64667 invoked by uid 89); 27 Feb 2018 07:10:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Feb 2018 07:10:32 +0000 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1R78phH102768 for ; Tue, 27 Feb 2018 02:10:31 -0500 Received: from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107]) by mx0b-001b2d01.pphosted.com with ESMTP id 2gd1y6hmxq-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 27 Feb 2018 02:10:30 -0500 Received: from localhost by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 27 Feb 2018 07:10:28 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp11.uk.ibm.com (192.168.101.141) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 27 Feb 2018 07:10:24 -0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w1R7AN8F55705720; Tue, 27 Feb 2018 07:10:23 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4811511C04C; Tue, 27 Feb 2018 07:03:18 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0178711C04A; Tue, 27 Feb 2018 07:03:17 +0000 (GMT) Received: from rapoport-lnx (unknown [9.148.8.77]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Tue, 27 Feb 2018 07:03:16 +0000 (GMT) Date: Tue, 27 Feb 2018 07:10:00 -0000 From: Mike Rapoport To: Nathan Hjelm Cc: Open MPI Developers , Andrei Vagin , Arnd Bergmann , Jann Horn , rr-dev@mozilla.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, Josh Triplett , criu@openvz.org, linux-mm@kvack.org, gdb@sourceware.org, Alexander Viro , Greg KH , linux-fsdevel@vger.kernel.org, Andrew Morton , Thomas Gleixner , Michael Kerrisk Subject: Re: [OMPI devel] [PATCH v5 0/4] vm: add a syscall to map a process memory into a pipe References: <1515479453-14672-1-git-send-email-rppt@linux.vnet.ibm.com> <20180220164406.3ec34509376f16841dc66e34@linux-foundation.org> <3122ec5a-7f73-f6b4-33ea-8c10ef32e5b0@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-TM-AS-GCONF: 00 x-cbid: 18022707-0040-0000-0000-000004383E01 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18022707-0041-0000-0000-000020DA6873 Message-Id: <20180227071020.GA24633@rapoport-lnx> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-02-27_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1802270085 X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00105.txt.bz2 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 atomics). I have not heard about this new proposal. What is > the benefit of the proposed calls over the existing calls? The proposed system call call that combines functionality of process_vm_read and vmsplice [1] and it's particularly useful when one needs to read the remote process memory and then write it to a file descriptor. In this case a sequence of process_vm_read() + write() calls that involves two copies of data can be replaced with process_vm_splice() + splice() which does not involve copy at all. [1] https://lkml.org/lkml/2018/1/9/32 > -Nathan > > > On Feb 26, 2018, at 2:02 AM, 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 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 -- Sincerely yours, Mike.