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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 DD519C35240 for ; Sun, 26 Jan 2020 23:39:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 84EB620702 for ; Sun, 26 Jan 2020 23:39:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="e7f4srva" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 84EB620702 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C773F6B0003; Sun, 26 Jan 2020 18:39:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C26886B0006; Sun, 26 Jan 2020 18:39:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B15A06B0007; Sun, 26 Jan 2020 18:39:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0100.hostedemail.com [216.40.44.100]) by kanga.kvack.org (Postfix) with ESMTP id 9AEB26B0003 for ; Sun, 26 Jan 2020 18:39:42 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 39064180AD804 for ; Sun, 26 Jan 2020 23:39:42 +0000 (UTC) X-FDA: 76421405004.12.pig70_8ed8fc4f18917 X-HE-Tag: pig70_8ed8fc4f18917 X-Filterd-Recvd-Size: 4798 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Sun, 26 Jan 2020 23:39:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HccNVAHYrxwNOkvIoab6izWsFUr3C25PEsIHXLsrgR4=; b=e7f4srvaUcflIy2OBKV4jiVAa Xflq/gHQssAbiSP2cMCfQBp+q6DHKlAbn/oTmfEUT80aAcuGTNs56GsICd+pberT7qMe25EjTGxVc r2QTBigxocuowetyeS2VqQ4SIdyy7BjrXHVjlgtwFDRW370aHY/qaQevdFJ+efChT/GmmBrgd24rE rAntuXZAwE5XCDxXuiwNursoCUR3Bjse+feleS/rnwoisvXpiGf1/m2J4DOSBGIK6zWXqqEdtxoZg FT7gSA/NkLl74qIni8PdoUTurXIOD/dxsgTC0l581Ol++Wrdo9H/vNKGutSrGyZas9tu31WxwEG82 lXxgvH7Rw==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1ivrV9-0006zd-BA; Sun, 26 Jan 2020 23:39:35 +0000 Date: Sun, 26 Jan 2020 15:39:35 -0800 From: Matthew Wilcox To: Cong Wang Cc: Michal Hocko , LKML , Andrew Morton , linux-mm , Mel Gorman , Vlastimil Babka Subject: Re: [PATCH] mm: avoid blocking lock_page() in kcompactd Message-ID: <20200126233935.GA11536@bombadil.infradead.org> References: <20200109225646.22983-1-xiyou.wangcong@gmail.com> <20200110073822.GC29802@dhcp22.suse.cz> <20200121090048.GG29276@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Sun, Jan 26, 2020 at 11:53:55AM -0800, Cong Wang wrote: > On Tue, Jan 21, 2020 at 1:00 AM Michal Hocko wrote: > > > > On Mon 20-01-20 14:48:05, Cong Wang wrote: > > > It got stuck somewhere along the call path of mem_cgroup_try_charge(), > > > and the trace events of mm_vmscan_lru_shrink_inactive() indicates this > > > too: > > > > So it seems that you are condending on the page lock. It is really > > unexpected that the reclaim would take that long though. Please try to > > enable more vmscan tracepoints to see where the time is spent. > > I suspect the process gets stuck in the retry loop in try_charge(), as > the _shortest_ stacktrace of the perf samples indicated: > > cycles:ppp: > ffffffffa72963db mem_cgroup_iter > ffffffffa72980ca mem_cgroup_oom_unlock > ffffffffa7298c15 try_charge > ffffffffa729a886 mem_cgroup_try_charge > ffffffffa720ec03 __add_to_page_cache_locked > ffffffffa720ee3a add_to_page_cache_lru > ffffffffa7312ddb iomap_readpages_actor > ffffffffa73133f7 iomap_apply > ffffffffa73135da iomap_readpages > ffffffffa722062e read_pages > ffffffffa7220b3f __do_page_cache_readahead > ffffffffa7210554 filemap_fault > ffffffffc039e41f __xfs_filemap_fault > ffffffffa724f5e7 __do_fault > ffffffffa724c5f2 __handle_mm_fault > ffffffffa724cbc6 handle_mm_fault > ffffffffa70a313e __do_page_fault > ffffffffa7a00dfe page_fault > > But I don't see how it could be, the only possible case is when > mem_cgroup_oom() returns OOM_SUCCESS. However I can't > find any clue in dmesg pointing to OOM. These processes in the > same memcg are either running or sleeping (that is not exiting or > coredump'ing), I don't see how and why they could be selected as > a victim of OOM killer. I don't see any signal pending either from > their /proc/X/status. I think this is a situation where we might end up with a genuine deadlock if we're not trylocking the pages. readahead allocates a batch of locked pages and adds them to the pagecache. If it has allocated, say, 5 pages, successfully inserted the first three into i_pages, then needs to allocate memory to insert the fourth one into i_pages, and the process then attempts to migrate the pages which are still locked, they will never come unlocked because they haven't yet been submitted to the filesystem for reading. Or is this enough? static inline gfp_t readahead_gfp_mask(struct address_space *x) return mapping_gfp_mask(x) | __GFP_NORETRY | __GFP_NOWARN;