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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E53F5EB64DC for ; Tue, 11 Jul 2023 11:07:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231455AbjGKLHX (ORCPT ); Tue, 11 Jul 2023 07:07:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42448 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229931AbjGKLHU (ORCPT ); Tue, 11 Jul 2023 07:07:20 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C9B7E9B for ; Tue, 11 Jul 2023 04:07:19 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 882342221F; Tue, 11 Jul 2023 11:07:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1689073638; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Y4gWIaFptjaLY0gO4SYc7/oxN1BeIn2RxSIV3l1pbVI=; b=cQQ19ZWD+YHfE1cYUbh+IxopPTDFVhV2vnrzifZbWdZt8+yBaSsyAJaYuuBvuZ1WYTaovp XKiASvwBg/VIykrenMYP/mqnAA7NZ2ot7tSFiOuxUbdqgK3ksGDx9YgbXJ5TnWIF0FHIVi t3Br1c8D8D4jAn7PfT1+iySi+dMCHN0= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 6B8AC1390F; Tue, 11 Jul 2023 11:07:18 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Xts8F+Y3rWTqEAAAMHmgww (envelope-from ); Tue, 11 Jul 2023 11:07:18 +0000 Date: Tue, 11 Jul 2023 13:07:17 +0200 From: Michal Hocko To: Huang Ying Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Arjan Van De Ven , Andrew Morton , Mel Gorman , Vlastimil Babka , David Hildenbrand , Johannes Weiner , Dave Hansen , Pavel Tatashin , Matthew Wilcox Subject: Re: [RFC 1/2] mm: add framework for PCP high auto-tuning Message-ID: References: <20230710065325.290366-1-ying.huang@intel.com> <20230710065325.290366-2-ying.huang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230710065325.290366-2-ying.huang@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 10-07-23 14:53:24, Huang Ying wrote: > The page allocation performance requirements of different workloads > are usually different. So, we often need to tune PCP (per-CPU > pageset) high to optimize the workload page allocation performance. > Now, we have a system wide sysctl knob (percpu_pagelist_high_fraction) > to tune PCP high by hand. But, it's hard to find out the best value > by hand. And one global configuration may not work best for the > different workloads that run on the same system. One solution to > these issues is to tune PCP high of each CPU automatically. > > This patch adds the framework for PCP high auto-tuning. With it, > pcp->high will be changed automatically by tuning algorithm at > runtime. Its default value (pcp->high_def) is the original PCP high > value calculated based on low watermark pages or > percpu_pagelist_high_fraction sysctl knob. To avoid putting too many > pages in PCP, the original limit of percpu_pagelist_high_fraction > sysctl knob, MIN_PERCPU_PAGELIST_HIGH_FRACTION, is used to calculate > the max PCP high value (pcp->high_max). It would have been very helpful to describe the basic entry points to the auto-tuning. AFAICS the central place of the tuning is tune_pcp_high which is called from the freeing path. Why? Is this really a good place considering this is a hot path? What about the allocation path? Isn't that a good spot to watch for the allocation demand? Also this framework seems to be enabled by default. Is this really desirable? What about workloads tuning the pcp batch size manually? Shouldn't they override any auto-tuning? -- Michal Hocko SUSE Labs