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=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham 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 DA5A8C433ED for ; Thu, 20 May 2021 01:22:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BCB66611AD for ; Thu, 20 May 2021 01:22:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230226AbhETBYM (ORCPT ); Wed, 19 May 2021 21:24:12 -0400 Received: from mga02.intel.com ([134.134.136.20]:64728 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230049AbhETBYM (ORCPT ); Wed, 19 May 2021 21:24:12 -0400 IronPort-SDR: dpDEAwo4cosxh7djoclagD3YJO9nrb0cDd/CyRKx7tsdRMijD5cpUt2WxqMY+DOx5KqSjDSgKZ mtruFU8Hf+ZQ== X-IronPort-AV: E=McAfee;i="6200,9189,9989"; a="188246568" X-IronPort-AV: E=Sophos;i="5.82,313,1613462400"; d="scan'208";a="188246568" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 May 2021 18:22:51 -0700 IronPort-SDR: PWfdGOb06qVDM6X27/4KBStD4pv/kuC00A1YSX6+Oy8t8xQP6JPZsr49wEn13KAimSly57HxQM je1fZtKIKKVg== X-IronPort-AV: E=Sophos;i="5.82,313,1613462400"; d="scan'208";a="440222333" 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; 19 May 2021 18:22:47 -0700 From: "Huang, Ying" To: Johannes Weiner Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Matthew Wilcox , Linus Torvalds , Peter Xu , Hugh Dickins , Mel Gorman , Rik van Riel , Andrea Arcangeli , Michal Hocko , Dave Hansen , Tim Chen Subject: Re: [PATCH] mm: move idle swap cache pages to the tail of LRU after COW References: <20210519013313.1274454-1-ying.huang@intel.com> Date: Thu, 20 May 2021 09:22:45 +0800 In-Reply-To: (Johannes Weiner's message of "Wed, 19 May 2021 10:49:33 -0400") Message-ID: <87r1i28ahm.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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Johannes Weiner writes: > On Wed, May 19, 2021 at 09:33:13AM +0800, Huang Ying wrote: >> diff --git a/mm/memory.c b/mm/memory.c >> index b83f734c4e1d..2b6847f4c03e 100644 >> --- a/mm/memory.c >> +++ b/mm/memory.c >> @@ -3012,6 +3012,11 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf) >> munlock_vma_page(old_page); >> unlock_page(old_page); >> } >> + if (page_copied && PageSwapCache(old_page) && >> + !page_mapped(old_page) && trylock_page(old_page)) { >> + try_to_free_idle_swapcache(old_page); >> + unlock_page(old_page); > > If there are no more swap or pte references, can we just attempt to > free the page right away, like we do during regular unmap? > > if (page_copied) > free_swap_cache(old_page); > put_page(old_page); A previous version of the patch does roughly this. https://lore.kernel.org/lkml/20210113024241.179113-1-ying.huang@intel.com/ But Linus has concerns with the overhead introduced in the hot COW path. Another possibility is to move the idle swap cache page to the tail of the file LRU list. But the question is how to identify the page. Best Regards, Huang, Ying