Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp402710imu; Fri, 7 Dec 2018 03:04:14 -0800 (PST) X-Google-Smtp-Source: AFSGD/X6ikj3ZXki2DhivdRNcSQVBAppoz3/Ag0QYK9IwzqGFnC9cY8a9M9uNX+jptHqvd80u3b6 X-Received: by 2002:a62:61c3:: with SMTP id v186mr1786261pfb.55.1544180654736; Fri, 07 Dec 2018 03:04:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544180654; cv=none; d=google.com; s=arc-20160816; b=JDgwLFRDj579okzqtHQRjntL8AhF+nVnRd8BJERbfUmCkOEMuzWJ2QoHAfj56gpTol foVkV8urJOt4HKMg+xuskgdtqRQeT9DeCs41xgTErwyYCszG9lYMobPi0mXjYlqPy7DP spKg2AymOHu5m94xzZLuPhrZykInjUWvCB2bX3glwlaEDP64Jzxp7097WgFl7pj7kupF f0DlB8AVDvmpnwW8Kn6EKAdWcXwk4xiG3FxUK1ya1DmHGHujtzEq/8YRhQt0jymCDxMH hpU8ILhFZsUWGK1qrXMGJy6oUFJayf4HZB6+AI6s41zMXnGRMHdp+T/HZfeYn41VRXXG rZ8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=2v6v2xRzQr+l8ml2/e4oysPYmZ7m12hnHvbjmq3U+qc=; b=xED3KGYM/iLkyMiWQFwGWWfqxEZK9xfrijL0gy8ZvaQRlFLB6bd6IYipQ3/VgujP/u y0oWvjP6w50nLWQpmTNr/B7sb0//xeUI9Ryre4l3dxbpWwBzUz8SXl9+BQU4ZFzvQdHX pf2QOfsGspQ6T6gv/Ef/3YPqfCJ2qEy9InitSl/+DH+XQmLAWiaeL3SDJEBARGClHHfG bhQWpDilJkenh7LE1j6VHLDBTvKw//olBErB9LeoloqzM2OHKzOG4QYNIPKbjT/Pd7Aw 2Jw9d55d206fCA/A738oeYGEo8F49JiAumdELdaJTKlMrlHOOo3IQ0xZubXTU+a23l5W JvzQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a4si2647510pls.262.2018.12.07.03.03.54; Fri, 07 Dec 2018 03:04:14 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726053AbeLGLDT (ORCPT + 99 others); Fri, 7 Dec 2018 06:03:19 -0500 Received: from mx2.suse.de ([195.135.220.15]:40112 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725997AbeLGLDT (ORCPT ); Fri, 7 Dec 2018 06:03:19 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 53C4BB004; Fri, 7 Dec 2018 11:03:17 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 0EF641E0D9D; Fri, 7 Dec 2018 12:03:17 +0100 (CET) Date: Fri, 7 Dec 2018 12:03:17 +0100 From: Jan Kara To: Josef Bacik Cc: Andrew Morton , kernel-team@fb.com, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, tj@kernel.org, david@fromorbit.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, riel@redhat.com, jack@suse.cz Subject: Re: [PATCH 4/4] mm: use the cached page for filemap_fault Message-ID: <20181207110317.GF13008@quack2.suse.cz> References: <20181130195812.19536-1-josef@toxicpanda.com> <20181130195812.19536-5-josef@toxicpanda.com> <20181204145034.4b69bdea36506be45946f8c9@linux-foundation.org> <20181205145808.kzsro4a7vqaxx3cu@MacBook-Pro-91.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181205145808.kzsro4a7vqaxx3cu@MacBook-Pro-91.local> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 05-12-18 09:58:10, Josef Bacik wrote: > On Tue, Dec 04, 2018 at 02:50:34PM -0800, Andrew Morton wrote: > > On Fri, 30 Nov 2018 14:58:12 -0500 Josef Bacik wrote: > > > > > If we drop the mmap_sem we have to redo the vma lookup which requires > > > redoing the fault handler. Chances are we will just come back to the > > > same page, so save this page in our vmf->cached_page and reuse it in the > > > next loop through the fault handler. > > > > > > > Is this really worthwhile? Rerunning the fault handler is rare (we > > hope) and a single pagecache lookup is fast. > > > > Some performance testing results would be helpful here. It's > > practically obligatory when claiming a performance improvement. > > > > > > Honestly the big thing is just not doing IO under the mmap_sem. I had this > infrastructure originally for the mkwrite portion of these patches that I > dropped, because I was worried about the page being messed with after we did all > the mkwrite work. However since I'm not doing that anymore there's less of a > need for it. I have no performance numbers for this, just seemed like a good > idea since we are likely to just have the page again, and this keeps us from > evicting the page right away and causing more thrashing. > > I'll try and set something up to see if there's a difference. If there's no > difference do you want me to drop this? Thanks, If there's no difference, I'd like to drop this as well. It just complicates the fault state handling which is already complex enough. Honza -- Jan Kara SUSE Labs, CR