From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752263AbcHKUfE (ORCPT ); Thu, 11 Aug 2016 16:35:04 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:34430 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751340AbcHKUfC convert rfc822-to-8bit (ORCPT ); Thu, 11 Aug 2016 16:35:02 -0400 MIME-Version: 1.0 In-Reply-To: <20160811200018.GA28271@lst.de> References: <87eg5w18iu.fsf@yhuang-mobile.sh.intel.com> <87a8gk17x7.fsf@yhuang-mobile.sh.intel.com> <8760r816wf.fsf@yhuang-mobile.sh.intel.com> <20160811155721.GA23015@lst.de> <874m6ryz0u.fsf@yhuang-mobile.sh.intel.com> <20160811200018.GA28271@lst.de> From: Linus Torvalds Date: Thu, 11 Aug 2016 13:35:00 -0700 X-Google-Sender-Auth: Dukj7ug0yCdi53xAsVqgKO-ihaM Message-ID: Subject: Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression To: Christoph Hellwig Cc: "Huang, Ying" , Dave Chinner , LKML , Bob Peterson , Wu Fengguang , LKP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 11, 2016 at 1:00 PM, Christoph Hellwig wrote: > > I can't really think of any reason why the pagefaul_disable() would > sŃ–gnificantly change performance. No, you're right, we prefault the page anyway. And quite frankly, looking at it, I think the pagefault_disable/enable is actually *correct*. The thing is, iov_iter_copy_from_user_atomic() doesn't itself enforce non-blocking user accesses, it depends on the caller blocking page faults. And the reason we want to block page faults is to make sure we don't deadlock on the page we just locked for writing. So looking at it, I think the pagefault_disable/enable is actually needed, and it may in fact be a bug that mm/filemap.c doesn't do that. However, see commit 00a3d660cbac ("Revert "fs: do not prefault sys_write() user buffer pages"") about why mm/filemap.c doesn't do the pagefault_disable(). But depending on the prefaulting actually guaranteeing that we don't deadlock sounds like a nasty race in theory (ie somebody does mmap tricks in another thread in between the pre-faulting and the final copying). Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============3993109120930258363==" MIME-Version: 1.0 From: Linus Torvalds To: lkp@lists.01.org Subject: Re: [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression Date: Thu, 11 Aug 2016 13:35:00 -0700 Message-ID: In-Reply-To: <20160811200018.GA28271@lst.de> List-Id: --===============3993109120930258363== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, Aug 11, 2016 at 1:00 PM, Christoph Hellwig wrote: > > I can't really think of any reason why the pagefaul_disable() would > s=D1=96gnificantly change performance. No, you're right, we prefault the page anyway. And quite frankly, looking at it, I think the pagefault_disable/enable is actually *correct*. The thing is, iov_iter_copy_from_user_atomic() doesn't itself enforce non-blocking user accesses, it depends on the caller blocking page faults. And the reason we want to block page faults is to make sure we don't deadlock on the page we just locked for writing. So looking at it, I think the pagefault_disable/enable is actually needed, and it may in fact be a bug that mm/filemap.c doesn't do that. However, see commit 00a3d660cbac ("Revert "fs: do not prefault sys_write() user buffer pages"") about why mm/filemap.c doesn't do the pagefault_disable(). But depending on the prefaulting actually guaranteeing that we don't deadlock sounds like a nasty race in theory (ie somebody does mmap tricks in another thread in between the pre-faulting and the final copying). Linus --===============3993109120930258363==--