Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp2515197pxb; Tue, 13 Apr 2021 04:00:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxzZfC7eFG218urHtuyUTzn/9K+pLz7Zxi2n7VP7pqCM/6xu3TkCA1WAaiTaQ9kr8B4kVqC X-Received: by 2002:a17:903:244:b029:e8:b80f:5f33 with SMTP id j4-20020a1709030244b02900e8b80f5f33mr31867180plh.75.1618311609452; Tue, 13 Apr 2021 04:00:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618311609; cv=none; d=google.com; s=arc-20160816; b=pEYhs0rcRuDqRO0Vw0jpBH9ujGRtvEAbzwr3Xit8sKndQ0/bvhUcizbqwJBFxQl7Ii TR3FQ1cgA6VhR8U9Sv8rg834InM8PXuyvd1sHWQpGd6rTf38y1CX05GzFxZuvJKBOk6v OLmAAxY16T7Pw8fquX7wtQgrupTABb+zl65oiV/OjLhxgoVFGQIjNh7VTj0YD2zxJbq3 aEOzKlHbE510L+dDItm2dtfP0VkbNyeQ0ri7XzG1ldC8Ay/N2gZmKR5PUDAG+7aOxa/4 XWjISx/z7FhthtJIM8QR2CPLs6ezBc30jNYo5YzEmFnN/jV3FmUQi/TevMmoVasyBzmS 3/WQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date:dkim-signature; bh=04YF3M1vfRP/894Mkgtm7cFlhBMi621lrF3NTwGcvuo=; b=oZk4TR6YWc29MmPF5a3V73FKRqmserjJWBX/Vy9V5ok9XEBtqBZxoYDFoVD7mlOm8H fqryF+mjLEyterf2jcIm6TrAC85kIY9cg35lEklM/ypN9UHlFEyBkHJvQgqOzY3Yudlc dlulmypUsjzS21louOvOBlQSoDK5prnEsLKzpnOgGOctc/dWsFevElIdEocNpcTw/N8R zLyjlKmhWAXI961Q7BMtw3RUOPwowcJjVvu9vlyRYoizM+PO/vzF8ghkuxmYHW5NAH24 VnBk+596gjKyjumMTvd01Wh3zGn6OOXpjS/fh2pwokw4nFWO4poefUGpVT6puI9u8nb7 tEsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=BwVBTRBs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j13si17163964pgs.434.2021.04.13.03.59.57; Tue, 13 Apr 2021 04:00:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=BwVBTRBs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244907AbhDLS0v (ORCPT + 99 others); Mon, 12 Apr 2021 14:26:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236888AbhDLS0s (ORCPT ); Mon, 12 Apr 2021 14:26:48 -0400 Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E2659C06174A for ; Mon, 12 Apr 2021 11:26:29 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id q10so10056202pgj.2 for ; Mon, 12 Apr 2021 11:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=04YF3M1vfRP/894Mkgtm7cFlhBMi621lrF3NTwGcvuo=; b=BwVBTRBsJxDqmmlOtB8bmKlBhQXbtnALtN8305m2UQPPu7O8SOqsfety1GQWN46GdQ Mk199hVidSasf6I9HMs7rUz40Jhhrnlca20rU38slO3ihLmxc0yUwI5l3Bo4WtT35NxC ggJ56+58XC1xnByQLAY087TVb4iG7ep1bHi+ZAwHlBUSEiexv9COfEJDIybuRifwqc0h vPfZqT4DFdjV6LTSrPvKzvDzN/LYaLY7NtvzBFLqS4zvKwlDoCUWPcBWEfSgQdUuoFYz QgoVVY5nnFStxxLDQN29Yc84m/Il7lckWG30UR70JawzZ0SlKX1qPWjzIyUxOzbBII7p FJGQ== 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:in-reply-to:message-id :references:mime-version; bh=04YF3M1vfRP/894Mkgtm7cFlhBMi621lrF3NTwGcvuo=; b=K1nRRSY4zIYGCwcqRJBdTAR49mWCYapZh5fte63bC+vA3SqfoPCsd1ySL3zw6Ipcs1 rFdaP7czlttLnfvhq1EWW5MY0VQohdLQD5A+hW2NHGc7YqZQicEjt09KjCFoJ368YQI0 2uAI66d6oYl4LEb6RZL3DH8THoqBfok3Vw0/Yr6LfYA1OTzDKp+eTykwtfALa1xiY/TI RlUKMNcsHzr1M1wDiJco2mHi+H9/CupRSReZSOB6OhMu5vtlwfE7RMTMk8J34O3FxN4S c42ISeiiBCTR6GaAzzBCLrGpY9EPalYEdYtD9F48xVJrzw3tkWIFuOCRinXxea6xjAk7 yyZQ== X-Gm-Message-State: AOAM532cbHv7nOWQbnVrUOIh9wrnaCBSBmj0aKRlTR+6suOTOcPFCxJy OYFHEW2i9Y+lj412VQ6+rxzqRA== X-Received: by 2002:aa7:8389:0:b029:209:da1c:17b5 with SMTP id u9-20020aa783890000b0290209da1c17b5mr26072167pfm.29.1618251989325; Mon, 12 Apr 2021 11:26:29 -0700 (PDT) Received: from [2620:15c:17:3:7835:226e:b31b:6f48] ([2620:15c:17:3:7835:226e:b31b:6f48]) by smtp.gmail.com with ESMTPSA id n4sm10676856pfu.45.2021.04.12.11.26.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Apr 2021 11:26:28 -0700 (PDT) Date: Mon, 12 Apr 2021 11:26:27 -0700 (PDT) From: David Rientjes To: chukaiping cc: mcgrof@kernel.org, keescook@chromium.org, yzaikin@google.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] mm/compaction:let proactive compaction order configurable In-Reply-To: <1618218330-50591-1-git-send-email-chukaiping@baidu.com> Message-ID: References: <1618218330-50591-1-git-send-email-chukaiping@baidu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 12 Apr 2021, chukaiping wrote: > Currently the proactive compaction order is fixed to > COMPACTION_HPAGE_ORDER(9), it's OK in most machines with lots of > normal 4KB memory, but it's too high for the machines with small > normal memory, for example the machines with most memory configured > as 1GB hugetlbfs huge pages. In these machines the max order of > free pages is often below 9, and it's always below 9 even with hard > compaction. This will lead to proactive compaction be triggered very > frequently. In these machines we only care about order of 3 or 4. > This patch export the oder to proc and let it configurable > by user, and the default value is still COMPACTION_HPAGE_ORDER. > I'm curious why you have proactive compaction enabled at all in this case? The order-9 threshold is likely to optimize for hugepage availability, but in your setup it appears that's not a goal. So what benefit does proactive compaction provide if only done for order-3 or order-4? > Signed-off-by: chukaiping > --- > include/linux/compaction.h | 1 + > kernel/sysctl.c | 10 ++++++++++ > mm/compaction.c | 7 ++++--- > 3 files changed, 15 insertions(+), 3 deletions(-) > > diff --git a/include/linux/compaction.h b/include/linux/compaction.h > index ed4070e..151ccd1 100644 > --- a/include/linux/compaction.h > +++ b/include/linux/compaction.h > @@ -83,6 +83,7 @@ static inline unsigned long compact_gap(unsigned int order) > #ifdef CONFIG_COMPACTION > extern int sysctl_compact_memory; > extern unsigned int sysctl_compaction_proactiveness; > +extern unsigned int sysctl_compaction_order; > extern int sysctl_compaction_handler(struct ctl_table *table, int write, > void *buffer, size_t *length, loff_t *ppos); > extern int sysctl_extfrag_threshold; > diff --git a/kernel/sysctl.c b/kernel/sysctl.c > index 62fbd09..277df31 100644 > --- a/kernel/sysctl.c > +++ b/kernel/sysctl.c > @@ -114,6 +114,7 @@ > static int __maybe_unused neg_one = -1; > static int __maybe_unused two = 2; > static int __maybe_unused four = 4; > +static int __maybe_unused ten = 10; > static unsigned long zero_ul; > static unsigned long one_ul = 1; > static unsigned long long_max = LONG_MAX; > @@ -2871,6 +2872,15 @@ int proc_do_static_key(struct ctl_table *table, int write, > .extra2 = &one_hundred, > }, > { > + .procname = "compaction_order", > + .data = &sysctl_compaction_order, > + .maxlen = sizeof(sysctl_compaction_order), > + .mode = 0644, > + .proc_handler = proc_dointvec_minmax, > + .extra1 = SYSCTL_ZERO, > + .extra2 = &ten, > + }, > + { > .procname = "extfrag_threshold", > .data = &sysctl_extfrag_threshold, > .maxlen = sizeof(int), > diff --git a/mm/compaction.c b/mm/compaction.c > index e04f447..a192996 100644 > --- a/mm/compaction.c > +++ b/mm/compaction.c > @@ -1925,16 +1925,16 @@ static bool kswapd_is_running(pg_data_t *pgdat) > > /* > * A zone's fragmentation score is the external fragmentation wrt to the > - * COMPACTION_HPAGE_ORDER. It returns a value in the range [0, 100]. > + * sysctl_compaction_order. It returns a value in the range [0, 100]. > */ > static unsigned int fragmentation_score_zone(struct zone *zone) > { > - return extfrag_for_order(zone, COMPACTION_HPAGE_ORDER); > + return extfrag_for_order(zone, sysctl_compaction_order); > } > > /* > * A weighted zone's fragmentation score is the external fragmentation > - * wrt to the COMPACTION_HPAGE_ORDER scaled by the zone's size. It > + * wrt to the sysctl_compaction_order scaled by the zone's size. It > * returns a value in the range [0, 100]. > * > * The scaling factor ensures that proactive compaction focuses on larger > @@ -2666,6 +2666,7 @@ static void compact_nodes(void) > * background. It takes values in the range [0, 100]. > */ > unsigned int __read_mostly sysctl_compaction_proactiveness = 20; > +unsigned int __read_mostly sysctl_compaction_order = COMPACTION_HPAGE_ORDER; > > /* > * This is the entry point for compacting all nodes via > -- > 1.7.1 > >