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=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 0ED9BC433B4 for ; Wed, 21 Apr 2021 02:39:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9AD6761403 for ; Wed, 21 Apr 2021 02:39:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9AD6761403 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0CB846B006C; Tue, 20 Apr 2021 22:39:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 07CD46B006E; Tue, 20 Apr 2021 22:39:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E5E6A6B0070; Tue, 20 Apr 2021 22:39:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0188.hostedemail.com [216.40.44.188]) by kanga.kvack.org (Postfix) with ESMTP id C8E366B006C for ; Tue, 20 Apr 2021 22:39:17 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 73A524853 for ; Wed, 21 Apr 2021 02:39:17 +0000 (UTC) X-FDA: 78054817554.33.A51344A Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf15.hostedemail.com (Postfix) with ESMTP id B8F4EA0000FD for ; Wed, 21 Apr 2021 02:39:13 +0000 (UTC) IronPort-SDR: GSZUzjspfWent5gSnDoEy/AysIlWVI19H5B7b4oSiuuafYJY99BmqtF3x3smBMza562VWD0VfX 65s9AQpQJrPA== X-IronPort-AV: E=McAfee;i="6200,9189,9960"; a="216262812" X-IronPort-AV: E=Sophos;i="5.82,238,1613462400"; d="scan'208";a="216262812" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2021 19:39:14 -0700 IronPort-SDR: K7XfZeMNVYpafHIWc7vTA4+M09/d5rQIU8zcG/Z3dVwBpFx7lKwed+FtYCFhTqHge/jQkeP4LC V5QB9dX1KukA== X-IronPort-AV: E=Sophos;i="5.82,238,1613462400"; d="scan'208";a="427337606" Received: from yhuang6-desk1.sh.intel.com (HELO yhuang6-desk1.ccr.corp.intel.com) ([10.239.13.1]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2021 19:39:11 -0700 From: "Huang, Ying" To: Michal Hocko Cc: Dave Hansen , Dave Hansen , linux-mm@kvack.org, linux-kernel@vger.kernel.org, yang.shi@linux.alibaba.com, rientjes@google.com, dan.j.williams@intel.com, david@redhat.com, osalvador@suse.de, weixugc@google.com Subject: Re: [PATCH 00/10] [v7][RESEND] Migrate Pages in lieu of discard References: <20210401183216.443C4443@viggo.jf.intel.com> <9cd0dcde-f257-1b94-17d0-f2e24a3ce979@intel.com> Date: Wed, 21 Apr 2021 10:39:09 +0800 In-Reply-To: (Michal Hocko's message of "Fri, 16 Apr 2021 17:02:23 +0200") Message-ID: <87czuo1hv6.fsf@yhuang6-desk1.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: B8F4EA0000FD X-Stat-Signature: 1pdikg3typh7364a5bfk6mwz6essgaro Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf15; identity=mailfrom; envelope-from=""; helo=mga01.intel.com; client-ip=192.55.52.88 X-HE-DKIM-Result: none/none X-HE-Tag: 1618972753-41371 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: Michal Hocko writes: > On Fri 16-04-21 07:26:43, Dave Hansen wrote: >> On 4/16/21 5:35 AM, Michal Hocko wrote: >> > - Anonymous pages are bit tricky because they can be demoted even when >> > they cannot be reclaimed due to no (or no available) swap storage. >> > Unless I have missed something the second round will try to reclaim >> > them even the later is true and I am not sure this is completely OK. >> >> What we want is something like this: >> >> Swap Space / Demotion OK -> Can Reclaim >> Swap Space / Demotion Off -> Can Reclaim >> Swap Full / Demotion OK -> Can Reclaim >> Swap Full / Demotion Off -> No Reclaim >> >> I *think* that's what can_reclaim_anon_pages() ends up doing. Maybe I'm >> misunderstanding what you are referring to, though. By "second round" >> did you mean when we do reclaim on a node which is a terminal node? > > No, I mean the migration failure case where you splice back to the page > list to reclaim. In that round you do not demote and want to reclaim. > But a lack of swap space will make that page unreclaimable. I suspect > this would just work out fine but I am not sure from the top of my head. I have tested this via injecting some migration errors (returning 0 from demote_page_list() before migration) on a system without swap. The system can still work properly. In ftrace, I can find add_to_swap() are called much more times, and it can deal with the situation where the swap space isn't available. Best Regards, Huang, Ying