From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 42965C47E49 for ; Wed, 6 Nov 2019 14:35:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0E1BB21D6C for ; Wed, 6 Nov 2019 14:35:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0E1BB21D6C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7B4BC6B0007; Wed, 6 Nov 2019 09:35:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 78B0B6B0008; Wed, 6 Nov 2019 09:35:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67A916B000A; Wed, 6 Nov 2019 09:35:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0238.hostedemail.com [216.40.44.238]) by kanga.kvack.org (Postfix) with ESMTP id 543726B0007 for ; Wed, 6 Nov 2019 09:35:44 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 0B79E180AD802 for ; Wed, 6 Nov 2019 14:35:44 +0000 (UTC) X-FDA: 76126101408.28.bike80_89524e2c1381b X-HE-Tag: bike80_89524e2c1381b X-Filterd-Recvd-Size: 3101 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Wed, 6 Nov 2019 14:35:43 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 95AB7B332; Wed, 6 Nov 2019 14:35:39 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 2E5811E4353; Wed, 6 Nov 2019 15:35:37 +0100 (CET) Date: Wed, 6 Nov 2019 15:35:37 +0100 From: Jan Kara To: snazy@snazy.de Cc: Jan Kara , Johannes Weiner , Vlastimil Babka , Michal Hocko , Josef Bacik , "Kirill A. Shutemov" , Randy Dunlap , linux-kernel@vger.kernel.org, Linux MM , Andrew Morton , "Potyra, Stefan" Subject: Re: mlockall(MCL_CURRENT) blocking infinitely Message-ID: <20191106143537.GI16085@quack2.suse.cz> References: <20191025132700.GJ17610@dhcp22.suse.cz> <707b72c6dac76c534dcce60830fa300c44f53404.camel@gmx.de> <20191025135749.GK17610@dhcp22.suse.cz> <20191025140029.GL17610@dhcp22.suse.cz> <20191105182211.GA33242@cmpxchg.org> <20191106120315.GF16085@quack2.suse.cz> <4edf4dea97f6c1e3c7d4fed0e12c3dc6dff7575f.camel@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4edf4dea97f6c1e3c7d4fed0e12c3dc6dff7575f.camel@gmx.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed 06-11-19 14:45:43, Robert Stupp wrote: > On Wed, 2019-11-06 at 13:03 +0100, Jan Kara wrote: > > On Tue 05-11-19 13:22:11, Johannes Weiner wrote: > > > What I don't quite understand yet is why the fault path doesn't > > > make > > > progress eventually. We must drop the mmap_sem without changing the > > > state in any way. How can we keep looping on the same page? > > > > That may be a slight suboptimality with Josef's patches. If the page > > is marked as PageReadahead, we always drop mmap_sem if we can and > > start > > readahead without checking whether that makes sense or not in > > do_async_mmap_readahead(). OTOH page_cache_async_readahead() then > > clears > > PageReadahead so the only way how I can see we could loop like this > > is when > > file->ra->ra_pages is 0. Not sure if that's what's happening through. > > We'd > > need to find which of the paths in filemap_fault() calls > > maybe_unlock_mmap_for_io() to tell more. > > Yes, ra_pages==0 OK, thanks for confirmation! > 5637e22a2000-5637e22a3000 r--p 00000000 103:02 49172550 /home/snazy/devel/misc/zzz/test What kind of device & fs does your /home stay on? I don't recognize the major number... Honza -- Jan Kara SUSE Labs, CR