Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp216442iob; Mon, 2 May 2022 17:29:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwz0N6YOmlU2dunwRfKtkIM0EozNqtXz1PEhJNAZkll1eiG+I3LKKmfqzLEnaUXkaseA0Nd X-Received: by 2002:a63:87c1:0:b0:3ab:254f:7aff with SMTP id i184-20020a6387c1000000b003ab254f7affmr11848280pge.341.1651537788803; Mon, 02 May 2022 17:29:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651537788; cv=none; d=google.com; s=arc-20160816; b=SFMa0gXy3kg8QHzF4eQ+v23BmtrjjC3u9RX1wQ5Bk7k7d5nWBu28+0nvTNfaiekiMS +BHS588mi0nLV8ZtIzzSlBkIAqaO5ZOVY3m99RqAKtXHDx8W0xi8ebRWTCQty9TLblGc 4pVxJhJJZtOqQpICPVbG4cpIuZcPNJeSBi7xE7gc01IOspbsNIu4ZZ16470kmozejFaU X6Y3L5esL7uVYD9BmAb5fi1rQjQmvd9RD7w6TosuRBlGuk0pa9zJ1Ku2rFqOWRx0Ey0J 0ckiCq46NvyVDGlH6/B6GgyyUlFvZ58PubfcSlCc3aN9/6S8n0djfaG/xBxt1dp5qnbq ApxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=X0xI846YgykHz7ukU/lLbMpzbPkcCjUF3g4NBh6Rmig=; b=lGe7X4wsfe3B5efljJwFeZNEw1DQwD4fvJrP82dIhzOSlarylyO/2a9KtKitInUxoe uEmZhGNN7/fIEv09+ao1EA+S4dezeoNlQmiJWh3QSvmaYI+I0z4B1SerwaA2bwX8rY2Z VSe40+P2Q3Itaj9lJWm4L1ieVtVqQpAzIoaMZ/NJwQ7V5DmNNKPu0YVz1QB3RLZ5J0ql MLCTccf0UFGyc2sH+VxwI6/k/MBRsqecz+nf5wv5taIxLXRc7SFE1A3ACyivXTeFm3LV vQ+cathv1Rh8YBrTMzr+teiEnitx/cCfbujostgwgEbYxY2AN0mvsCFasYfp5st8yNpQ xiEw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=mgeN3VVm; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id b11-20020a170902ed0b00b00158d1f2d451si14107266pld.45.2022.05.02.17.29.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 May 2022 17:29:48 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=mgeN3VVm; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 43E633FBCF; Mon, 2 May 2022 17:24:09 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244079AbiD3SmK (ORCPT + 99 others); Sat, 30 Apr 2022 14:42:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41314 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237413AbiD3SmI (ORCPT ); Sat, 30 Apr 2022 14:42:08 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 53171286F1 for ; Sat, 30 Apr 2022 11:38:45 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DECD360F9B for ; Sat, 30 Apr 2022 18:38:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04EACC385AA; Sat, 30 Apr 2022 18:38:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1651343924; bh=0kM/bEs+g1gOFSB9VF1SRjrnl2Jg+odHTRMiA+YRZbU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=mgeN3VVmKBNqS5F1fJjP+uFVBus1BjgNrNcklhgB//33m4Njw7MXJgdIUJa1dbzqJ bzghRIti9rqpT6dvLHFpwoUm+gQLWw6zY2O/XSV11j8SqP1C0EahIZrbgtVI7sTpnk NHGSzOm7di8TftrCHI0S4cGJc3KgAyR2mEB7hWNU= Date: Sat, 30 Apr 2022 11:38:43 -0700 From: Andrew Morton To: Wonhyuk Yang Cc: Mel Gorman , Ohhoon Kwon , JaeSang Yoo , Jiyoup Kim , Donghyeok Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/page_alloc: cache the result of node_dirty_ok() Message-Id: <20220430113843.7350160cf329e2a732e1cb94@linux-foundation.org> In-Reply-To: <20220430011032.64071-1-vvghjk1234@gmail.com> References: <20220430011032.64071-1-vvghjk1234@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE 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: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 30 Apr 2022 10:10:32 +0900 Wonhyuk Yang wrote: > To spread dirty page, nodes are checked whether > it reached the dirty limit using the expensive > node_dirty_ok(). To reduce the number of calling > node_dirty_ok(), last node that hit the dirty > limit is cached. > > Instead of caching the node, caching both node > and it's result of node_dirty_ok() can reduce > the number of calling node_dirty_ok() more than > before. > > ... > > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -4068,7 +4068,8 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags, > { > struct zoneref *z; > struct zone *zone; > - struct pglist_data *last_pgdat_dirty_limit = NULL; > + struct pglist_data *last_pgdat = NULL; > + bool last_pgdat_dirty_limit = false; > bool no_fallback; > > retry: > @@ -4107,13 +4108,13 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags, > * dirty-throttling and the flusher threads. > */ > if (ac->spread_dirty_pages) { > - if (last_pgdat_dirty_limit == zone->zone_pgdat) > - continue; > + if (last_pgdat != zone->zone_pgdat) { > + last_pgdat = zone->zone_pgdat; > + last_pgdat_dirty_limit = node_dirty_ok(zone->zone_pgdat); > + } > > - if (!node_dirty_ok(zone->zone_pgdat)) { > - last_pgdat_dirty_limit = zone->zone_pgdat; > + if (!last_pgdat_dirty_limit) > continue; > - } > } > > if (no_fallback && nr_online_nodes > 1 && Looks reasonable to me. Hopefully Mel and Johannes can review. I think last_pgdat_dirty_limit isn't a great name. It records the dirty_ok state of last_pgdat. So why not call it last_pgdat_dirty_ok? --- a/mm/page_alloc.c~mm-page_alloc-cache-the-result-of-node_dirty_ok-fix +++ a/mm/page_alloc.c @@ -4022,7 +4022,7 @@ get_page_from_freelist(gfp_t gfp_mask, u struct zoneref *z; struct zone *zone; struct pglist_data *last_pgdat = NULL; - bool last_pgdat_dirty_limit = false; + bool last_pgdat_dirty_ok = false; bool no_fallback; retry: @@ -4063,10 +4063,10 @@ retry: if (ac->spread_dirty_pages) { if (last_pgdat != zone->zone_pgdat) { last_pgdat = zone->zone_pgdat; - last_pgdat_dirty_limit = node_dirty_ok(zone->zone_pgdat); + last_pgdat_dirty_ok = node_dirty_ok(zone->zone_pgdat); } - if (!last_pgdat_dirty_limit) + if (!last_pgdat_dirty_ok) continue; } _