Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758759Ab3GZQrl (ORCPT ); Fri, 26 Jul 2013 12:47:41 -0400 Received: from www.sr71.net ([198.145.64.142]:44727 "EHLO blackbird.sr71.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758107Ab3GZQri (ORCPT ); Fri, 26 Jul 2013 12:47:38 -0400 Message-ID: <51F2A81E.5050500@sr71.net> Date: Fri, 26 Jul 2013 09:47:26 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Alexander Viro , Rik van Riel , Andrea Arcangeli , Matt Helsley , Anthony Liguori , Michael Roth , Lei Li , Leonardo Garcia Subject: Re: [RFC PATCH 1/2] vmsplice unmap gifted pages for recipient References: <1374772906-21511-1-git-send-email-rcj@linux.vnet.ibm.com> <1374772906-21511-2-git-send-email-rcj@linux.vnet.ibm.com> <51F160A5.2040004@sr71.net> <20130726151621.GA5037@linux.vnet.ibm.com> In-Reply-To: <20130726151621.GA5037@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1232 Lines: 28 On 07/26/2013 08:16 AM, Robert Jennings wrote: >>> > > + if ((spd->flags & SPLICE_F_MOVE) && >>> > > + !buf->offset && (buf->len == PAGE_SIZE)) >>> > > + /* Can move page aligned buf */ >>> > > + zap_buf_page(useraddr); >>> > > buf->flags |= PIPE_BUF_FLAG_GIFT; >>> > > + } >> > >> > There isn't quite enough context here, but is it going to do this >> > zap_buf_page() very often? Seems a bit wasteful to do the up/down and >> > find_vma() every trip through the loop. > The call to zap_buf_page() is in a loop where each pipe buffer is being > processed, but in that loop we have a pipe_wait() where we schedule(). > So as things are structured I don't have the ability to hold mmap_sem > for multiple find_vma() calls. You can hold a semaphore over a schedule(). :) You could also theoretically hold mmap_sem and only drop it on actual cases when you reschedule if you were afraid of holding mmap_sem for long periods of time (even though it's a read). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/