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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8547EB64DA for ; Fri, 14 Jul 2023 11:41:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 221176B0071; Fri, 14 Jul 2023 07:41:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D05D6B0072; Fri, 14 Jul 2023 07:41:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0988C6B0074; Fri, 14 Jul 2023 07:41:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id ED54E6B0071 for ; Fri, 14 Jul 2023 07:41:33 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A28CD120207 for ; Fri, 14 Jul 2023 11:41:33 +0000 (UTC) X-FDA: 81010027266.16.B38155E Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf01.hostedemail.com (Postfix) with ESMTP id A25A440012 for ; Fri, 14 Jul 2023 11:41:31 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=XQo5MHIA; spf=pass (imf01.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689334892; a=rsa-sha256; cv=none; b=UPSP1JdimwSnqqfny8jOeHhGf6enKVAxEIbnyitHxPRz5Fm+5WOHEbncm891SzCGQcGap+ tlj8hihEz68ehPF0LVmQkuXexXxSuWpXC7sd/tQVFnT4fopUVO5nKlUQHaPAdCBjGXgBNI d1pAFNj89XEqPZ3ubU3rBLuft8bHIPQ= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=XQo5MHIA; spf=pass (imf01.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689334892; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=iilSheHIUhgnsn15zN9O4xrXzcgpGmmRPakgPtr45AM=; b=TsjDQIw7t/cPyV7t07Btd4CmwwtQb04Ec2gKVZlF8Y03eG6xDnNaK21p2Q1vTgo3ePWfUZ H6LxeL8yzbDjLl/w4/GNa861KxsdxmwELjNfnCr9n9bIdWYK/3J42z7M6nR5S2AKayWNHO PID/EAufdgp0JdIbzpMJntcIOH5V5pA= 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 00ADA2209F; Fri, 14 Jul 2023 11:41:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1689334890; 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=iilSheHIUhgnsn15zN9O4xrXzcgpGmmRPakgPtr45AM=; b=XQo5MHIA02k7FaZ/QWVO6OpYvFpMXlPWusvgWQ6WpC3IdDJEGdWpcJkM/nwl/8we72XFfn Z5QLr1PW+J58HRL0qHho+YJUudt5t25D5W8L8XaWxuG4iQuhm76O/EDDoBjLEO38ArXIUI pG7wRONnYxbgMTQrMgxR97oqYr79nFo= 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 D588F138F8; Fri, 14 Jul 2023 11:41:29 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Gbf1MWk0sWTdOQAAMHmgww (envelope-from ); Fri, 14 Jul 2023 11:41:29 +0000 Date: Fri, 14 Jul 2023 13:41:28 +0200 From: Michal Hocko To: Mel Gorman Cc: Huang Ying , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Arjan Van De Ven , Andrew Morton , Vlastimil Babka , David Hildenbrand , Johannes Weiner , Dave Hansen , Pavel Tatashin , Matthew Wilcox Subject: Re: [RFC 2/2] mm: alloc/free depth based PCP high auto-tuning Message-ID: References: <20230710065325.290366-1-ying.huang@intel.com> <20230710065325.290366-3-ying.huang@intel.com> <20230712090526.thk2l7sbdcdsllfi@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230712090526.thk2l7sbdcdsllfi@techsingularity.net> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: A25A440012 X-Stat-Signature: e6cpuzzi4t33uimpyo9txexaifrh17i9 X-Rspam-User: X-HE-Tag: 1689334891-792299 X-HE-Meta: U2FsdGVkX186pmmYR+5shhSYPegVvz+lE3qoXQ9YdcUgVV+3rrrflpEvjHoj6ls42y6jeYXoxhudQZoImkcc4sT9tWkRjJxgppmECtUJYZmmoxlzGKm3jVTQDNtkFyDKb2UELPSRfNsRmT5qV4Dlyupqg9/FTHfuYVSFtDL+U81StT0KyA/yaQ526cl75P+3CtPO2LHaA17m2MOTXUKETCOm0m+Ul9nY05s9ARY71a/Fl5agOWFCWGHiOwr94jBIJG9EjWAfbS3N1Pgyl68tFf0+NndO0APkRdHiVDhuy8ateOwdWlLHWO3Ibz7m4ECVHy/X0O1RiK0vT86sT6ned0NoeBc0svr2FS/H/trTqQzhL4106WxtjaHyWOa4j6CoHbzmTR+EuIMjnLgy7bBjaA8lHgYd4d/WQiLe0aGHA4zx8rtP1s3O2YwGUEs1zwZiokEjjtgtZyxMJkz+SDUkZ4Ha1rcVxYZw6yhLJGb+Ffcqf4p19iCu2OzdKd4925PhSmSIA6oD5O7jOGMPwFDlF2CiM1/jmDlp9l1p7b6aM/B3zKwAQC9gO3aQ/NlXGwZAcQJ4FpK6/wRg0KtnfNZla8vlanc1Pg+ZBQpd7AGNlIhmzRMK9UBBu+xFI9UqVvy6yLTBjK1siNBdtL3nX3NKWGMnGv3AMRjqiDoQkuvas5axoqRs2X0pEbSJDZd2dCei8LktwH362z0iu9ndKOorlq7fIECHcHGpsPYGjen0fv4EdLZFNs4apNrk2zmefxDvBw2TfuzU9xa5dHF8GldEH8eEqjKm+5tJC+6jJeAdcRwOV82nGaEB2PVLBXbotm2z/szgYT3L56LRTuXQap8+K9z9zvnuly6q077MM2iP29LVKqEI0jGBmlKW2fGBotS9HOJffujuL7gI1YsJwNN/zyJqerVN5wb8k71rXiLHzpOAEaylHTvFc2WBloU/Djg2j1XS/x+GRa6Z4vrwvEL DpTvbK1y Zf6C/yQkeC4oq4OblnYRZNq7AVZazD5TSPE7vJF5DgVR2bf474khabSewRJgCdM3z8MBcp6Fgi4KNX5jlpUNi4zTJfuFuGv+i5zRUucdNeYZdSinv8XqvKzse3lsXtiIICOAbzPygyGc5/IDPX+jYpNWl9Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed 12-07-23 10:05:26, Mel Gorman wrote: > On Tue, Jul 11, 2023 at 01:19:46PM +0200, Michal Hocko wrote: > > On Mon 10-07-23 14:53:25, Huang Ying wrote: > > > To auto-tune PCP high for each CPU automatically, an > > > allocation/freeing depth based PCP high auto-tuning algorithm is > > > implemented in this patch. > > > > > > The basic idea behind the algorithm is to detect the repetitive > > > allocation and freeing pattern with short enough period (about 1 > > > second). The period needs to be short to respond to allocation and > > > freeing pattern changes quickly and control the memory wasted by > > > unnecessary caching. > > > > 1s is an ethernity from the allocation POV. Is a time based sampling > > really a good choice? I would have expected a natural allocation/freeing > > feedback mechanism. I.e. double the batch size when the batch is > > consumed and it requires to be refilled and shrink it under memory > > pressure (GFP_NOWAIT allocation fails) or when the surplus grows too > > high over batch (e.g. twice as much). Have you considered something as > > simple as that? > > Quite honestly I am not sure time based approach is a good choice > > because memory consumptions tends to be quite bulky (e.g. application > > starts or workload transitions based on requests). > > > > I tend to agree. Tuning based on the recent allocation pattern without frees > would make more sense and also be symmetric with how free_factor works. I > suspect that time-based may be heavily orientated around the will-it-scale > benchmark. While I only glanced at this, a few things jumped out > > 1. Time-based heuristics are not ideal. congestion_wait() and > friends was an obvious case where time-based heuristics fell apart even > before the event it waited on was removed. For congestion, it happened to > work for slow storage for a while but that was about it. For allocation > stream detection, it has a similar problem. If a process is allocating > heavily, then fine, if it's in bursts of less than a second more than one > second apart then it will not adapt. While I do not think it is explicitly > mentioned anywhere, my understanding was that heuristics like this within > mm/ should be driven by explicit events as much as possible and not time. Agreed. I would also like to point out that it is also important to realize those events that we should care about. Remember the primary motivation of the tuning is to reduce the lock contention. That being said, it is less of a problem to have stream or bursty demand for memory if that doesn't really cause the said contention, right? So any auto-tuning should consider that as well and do not inflate the batch in an absense of the contention. That of course means that a solely deallocation based monitoring. -- Michal Hocko SUSE Labs