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=-1.0 required=3.0 tests=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 CFEFFC2D0DB for ; Mon, 27 Jan 2020 15:00:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9994B20716 for ; Mon, 27 Jan 2020 15:00:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9994B20716 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2E7FC6B0007; Mon, 27 Jan 2020 10:00:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 298A46B0008; Mon, 27 Jan 2020 10:00:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B0076B000A; Mon, 27 Jan 2020 10:00:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0199.hostedemail.com [216.40.44.199]) by kanga.kvack.org (Postfix) with ESMTP id 02DB86B0007 for ; Mon, 27 Jan 2020 10:00:28 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 930DF180AD801 for ; Mon, 27 Jan 2020 15:00:28 +0000 (UTC) X-FDA: 76423725336.08.cakes22_2129f7a73fd28 X-HE-Tag: cakes22_2129f7a73fd28 X-Filterd-Recvd-Size: 5573 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Mon, 27 Jan 2020 15:00:27 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id q6so11643760wro.9 for ; Mon, 27 Jan 2020 07:00:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=MPyJz022JuT6nWadTd9aeXgqhFJalpTc13NsnVwngMg=; b=ChslT504wzw5qPV4ZHKbs/7hZiZVASZbAx7MND54Ir0E/HTlEZyhVIVKh+eItsn2+i qqE4jl4N6fw4r/WmYAY3CXjnWL72s5yE8Qp0FJlygJsb199H+gobipw+NFqoSKc9gvvs MgnoMjwjFS20KLr3Gftxrg/0Avkpheu5t2tUxwA+cslFO67qe4t+DZtpTVgTuhyzVq9Q np6WlyAJb/tt1OZM2k425mX5EW/8tiwQdQd6vMfBYGOV/mUUTyRYpGB5CYz8ZT1z6q6q 2PuBT+0K0jYRqr8yg2iVwJPxw0dw+TQTEVqsJLmdNSpQ++blYmmDr6x2gPb59SgY40lz sikw== X-Gm-Message-State: APjAAAUQNOq8RxT9bGRbZddd2wj9PtnKzRgJqNwTxlO65cIOkYcc7GRm Klzb18wFVinZvr0WHlOTUPU= X-Google-Smtp-Source: APXvYqz27KTaDhfMesbzgiDyVLK2MXuK2H8DrJuSl0WAcL8wm9ZEsn879LIR3Do094GYGWkHi8gmjA== X-Received: by 2002:a5d:4cc9:: with SMTP id c9mr22186112wrt.70.1580137226712; Mon, 27 Jan 2020 07:00:26 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id d14sm22645106wru.9.2020.01.27.07.00.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Jan 2020 07:00:25 -0800 (PST) Date: Mon, 27 Jan 2020 16:00:24 +0100 From: Michal Hocko To: Matthew Wilcox Cc: Cong Wang , LKML , Andrew Morton , linux-mm , Mel Gorman , Vlastimil Babka Subject: Re: [PATCH] mm: avoid blocking lock_page() in kcompactd Message-ID: <20200127150024.GN1183@dhcp22.suse.cz> References: <20200109225646.22983-1-xiyou.wangcong@gmail.com> <20200110073822.GC29802@dhcp22.suse.cz> <20200121090048.GG29276@dhcp22.suse.cz> <20200126233935.GA11536@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200126233935.GA11536@bombadil.infradead.org> 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 26-01-20 15:39:35, Matthew Wilcox wrote: > 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. Just to make sure I understand. Do you mean this? lock_page(A) alloc_pages try_to_compact_pages compact_zone_order compact_zone(MIGRATE_SYNC_LIGHT) migrate_pages unmap_and_move __unmap_and_move lock_page(A) -- Michal Hocko SUSE Labs