Message ID | 1680086855-7989-1-git-send-email-zhaoyang.huang@unisoc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp321669vqo; Wed, 29 Mar 2023 03:59:47 -0700 (PDT) X-Google-Smtp-Source: AKy350bKPSFOneWM+S1uI6VsEYClOr+0lQj6003M+m8XUUvOymrGIb8oIcS64pEC4ZAaA6BZ5Nwi X-Received: by 2002:a17:902:ecc3:b0:1a1:e237:5f0 with SMTP id a3-20020a170902ecc300b001a1e23705f0mr23692261plh.58.1680087587244; Wed, 29 Mar 2023 03:59:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680087587; cv=none; d=google.com; s=arc-20160816; b=BIAXLbXAEsQeXuKR1wquvUfK0Nt7jUnrijGo8X0lWjX/Aqcj81WpHdr45efBsDQTxX C7D8vVDWch+bPbYTRcKF3HnAyCY8mjMi392SEdHPoKPJocG0L2a4P4lqPcdpQgxUU5rR fJaEZGkjMmmpthBLaXT6MaP2Fm4u35FQ/Uva4Fm79jAkTkwoYsYSI49DK4Fh7SJxBFQt tPhn2qrT27jHHZ9xCH20WK4vw1otyxieLIr62ShOT+S9y8Q7dM0SebhnV9fMg6TV1MOz x4stkSb0sftSsjU0Zv2TmFY4gORpzA/f4qJoOsZugr5Z1sliBaU+Vntp8K0wL4qvLpmv ElkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:to:from; bh=JDsgX5hU+79t1EGeMejbU9n1MCVJlPWcOjWCjqkX9Qs=; b=UWBm76Ee7dhOb4GvinPuXaMo8hrn3HMzuDfbkrb13NXvi39eM6Bt5D5udJvKgqFRgW 7Itd6lyAgJORCD6s97A0ssKJQDWv3l1IS9kAgZyQj7WEvVBT3Ni0JVVomudv99ZIPAok I0kDBt1hoIAL2IkyO5WKHqrIggL0OQ89PrVxoXNlU3ycldwLbYP68cuEjsWW763IuhIZ SD4Oo0pD9iWPGSpoSK7/t4Hv09atBMx4HEwLFmvIAcpTNSmaJTPfrMmRIXPEIvGtFb3S B5rMBOHYNQCkn3a99JQRBZ6WMOKb7QLvP1uDH5GT3OK/cSlotryuwCiVWvHVtWAZIBYx PJ2A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x6-20020a63fe46000000b005138c1f1fcasi739116pgj.149.2023.03.29.03.59.34; Wed, 29 Mar 2023 03:59:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230367AbjC2Ksa (ORCPT <rfc822;rua109.linux@gmail.com> + 99 others); Wed, 29 Mar 2023 06:48:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51190 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229918AbjC2Ks3 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 29 Mar 2023 06:48:29 -0400 Received: from SHSQR01.spreadtrum.com (unknown [222.66.158.135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D74851FC3 for <linux-kernel@vger.kernel.org>; Wed, 29 Mar 2023 03:48:26 -0700 (PDT) Received: from SHSend.spreadtrum.com (bjmbx01.spreadtrum.com [10.0.64.7]) by SHSQR01.spreadtrum.com with ESMTP id 32TAlrt7027417; Wed, 29 Mar 2023 18:47:53 +0800 (+08) (envelope-from zhaoyang.huang@unisoc.com) Received: from bj03382pcu.spreadtrum.com (10.0.74.65) by BJMBX01.spreadtrum.com (10.0.64.7) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Wed, 29 Mar 2023 18:47:51 +0800 From: "zhaoyang.huang" <zhaoyang.huang@unisoc.com> To: Andrew Morton <akpm@linux-foundation.org>, Johannes Weiner <hannes@cmpxchg.org>, <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>, Zhaoyang Huang <huangzhaoyang@gmail.com>, <ke.wang@unisoc.com> Subject: [PATCH] mm: mark folio as workingset in lru_deactivate_fn Date: Wed, 29 Mar 2023 18:47:35 +0800 Message-ID: <1680086855-7989-1-git-send-email-zhaoyang.huang@unisoc.com> X-Mailer: git-send-email 1.9.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.0.74.65] X-ClientProxiedBy: SHCAS03.spreadtrum.com (10.0.1.207) To BJMBX01.spreadtrum.com (10.0.64.7) X-MAIL: SHSQR01.spreadtrum.com 32TAlrt7027417 X-Spam-Status: No, score=0.0 required=5.0 tests=SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761699521566606201?= X-GMAIL-MSGID: =?utf-8?q?1761699521566606201?= |
Series |
mm: mark folio as workingset in lru_deactivate_fn
|
|
Commit Message
zhaoyang.huang
March 29, 2023, 10:47 a.m. UTC
From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> folio will skip of being set as workingset in lru_deactivate_fn. Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com> --- mm/swap.c | 2 ++ 1 file changed, 2 insertions(+)
Comments
On Wed, Mar 29, 2023 at 06:47:35PM +0800, zhaoyang.huang wrote: > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > folio will skip of being set as workingset in lru_deactivate_fn. Can you please elaborate why that's undesirable? What's the problem you're fixing?
On Wed, Mar 29, 2023 at 10:55 PM Johannes Weiner <hannes@cmpxchg.org> wrote: > > On Wed, Mar 29, 2023 at 06:47:35PM +0800, zhaoyang.huang wrote: > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > > > folio will skip of being set as workingset in lru_deactivate_fn. > > Can you please elaborate why that's undesirable? What's the problem > you're fixing? If I am correct, folio will skip being set as workingset when moving from active lru to inactive lru, which is performed on every folio in shrink_active_list during normal reclaim.
On Thu, Mar 30, 2023 at 09:38:48AM +0800, Zhaoyang Huang wrote: > On Wed, Mar 29, 2023 at 10:55 PM Johannes Weiner <hannes@cmpxchg.org> wrote: > > > > On Wed, Mar 29, 2023 at 06:47:35PM +0800, zhaoyang.huang wrote: > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > > > > > folio will skip of being set as workingset in lru_deactivate_fn. > > > > Can you please elaborate why that's undesirable? What's the problem > > you're fixing? > If I am correct, folio will skip being set as workingset when moving > from active lru to inactive lru, which is performed on every folio in > shrink_active_list during normal reclaim. shrink_active_list directly calls folio_set_workingset(). The function you're editing is used for things like MADV_COLD and truncate(). It sounds like there is just a misunderstanding of the code, not an actual problem.
On Thu, Mar 30, 2023 at 5:32 PM Johannes Weiner <hannes@cmpxchg.org> wrote: > > On Thu, Mar 30, 2023 at 09:38:48AM +0800, Zhaoyang Huang wrote: > > On Wed, Mar 29, 2023 at 10:55 PM Johannes Weiner <hannes@cmpxchg.org> wrote: > > > > > > On Wed, Mar 29, 2023 at 06:47:35PM +0800, zhaoyang.huang wrote: > > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > > > > > > > folio will skip of being set as workingset in lru_deactivate_fn. > > > > > > Can you please elaborate why that's undesirable? What's the problem > > > you're fixing? > > If I am correct, folio will skip being set as workingset when moving > > from active lru to inactive lru, which is performed on every folio in > > shrink_active_list during normal reclaim. > > shrink_active_list directly calls folio_set_workingset(). The function > you're editing is used for things like MADV_COLD and truncate(). Yes. > > It sounds like there is just a misunderstanding of the code, not an > actual problem. Isn't that a problem? As my understanding, MADV_COLD could be deemed as a stimulation of normal reclaiming which turbo the folio towards eviction, while the page moving by it should be also delt in the same way(PG_active has been cleaned)
On Thu, Mar 30, 2023 at 5:41 PM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote: > > On Thu, Mar 30, 2023 at 5:32 PM Johannes Weiner <hannes@cmpxchg.org> wrote: > > > > On Thu, Mar 30, 2023 at 09:38:48AM +0800, Zhaoyang Huang wrote: > > > On Wed, Mar 29, 2023 at 10:55 PM Johannes Weiner <hannes@cmpxchg.org> wrote: > > > > > > > > On Wed, Mar 29, 2023 at 06:47:35PM +0800, zhaoyang.huang wrote: > > > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > > > > > > > > > folio will skip of being set as workingset in lru_deactivate_fn. > > > > > > > > Can you please elaborate why that's undesirable? What's the problem > > > > you're fixing? > > > If I am correct, folio will skip being set as workingset when moving > > > from active lru to inactive lru, which is performed on every folio in > > > shrink_active_list during normal reclaim. > > > > shrink_active_list directly calls folio_set_workingset(). The function > > you're editing is used for things like MADV_COLD and truncate(). > Yes. > > > > It sounds like there is just a misunderstanding of the code, not an > > actual problem. > Isn't that a problem? As my understanding, MADV_COLD could be deemed > as a stimulation of normal reclaiming which turbo the folio towards > eviction, while the page moving by it should be also delt in the same > way(PG_active has been cleaned) Sorry, I am still confused. Does it mean the pages deactivated via MADV_COLD like methods should NOT be deemed as workingset pages?
diff --git a/mm/swap.c b/mm/swap.c index 70e2063..4d1c14f 100644 --- a/mm/swap.c +++ b/mm/swap.c @@ -603,6 +603,7 @@ static void lru_deactivate_file_fn(struct lruvec *lruvec, struct folio *folio) lruvec_del_folio(lruvec, folio); folio_clear_active(folio); folio_clear_referenced(folio); + folio_set_workingset(folio); if (folio_test_writeback(folio) || folio_test_dirty(folio)) { /* @@ -637,6 +638,7 @@ static void lru_deactivate_fn(struct lruvec *lruvec, struct folio *folio) lruvec_del_folio(lruvec, folio); folio_clear_active(folio); folio_clear_referenced(folio); + folio_set_workingset(folio); lruvec_add_folio(lruvec, folio); __count_vm_events(PGDEACTIVATE, nr_pages);