Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp4762984pxb; Thu, 14 Oct 2021 11:27:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxO3rq0UTQ/6JDTdbu0m4n5p5ZTkzRPCPPBflg8Mz4RyIjSStRKRr04PSeH9iuLMORI541H X-Received: by 2002:a63:ab02:: with SMTP id p2mr3754202pgf.258.1634236060248; Thu, 14 Oct 2021 11:27:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634236060; cv=none; d=google.com; s=arc-20160816; b=Az21RSQQzde7T0ij5jB4cfE/+aWdxgHZOZ5p3IhVXyDlTdJ6QOQl+dmk1Vbw2Wvz87 tgFBzww681VY5atEoa77ieoeo8gGlZ6mDoTzzu4acX/fS5h1f3Q5pNd8AaScTBV9PHOe 6CnNsx38kKUv13vYL543wIKXuudh6BpNVkTWndKZvK1SAgGgG6ZmlSenr8vLR4aUGWKD Z/FVKXV+ouZLiZcizfEme+WDvwrwR4n0d7a24B04eiNyuhLFQR807uckbWPVwgbHz/Rt M/Dz+E+NW2qveJtWFsI/tMncfGSFFjZIE38xEB2XK49PN1lkbrC0LN+FKeBlczAGWPUn JRtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature:dkim-signature; bh=GxLH0z7C+H9xHqrBRI+kBoQatoT6Befch1xXUBOMRvk=; b=qwvqJwobgJQkY0DaKjB6nTTRfl3y1V1sEAT1JayrxMCpXC07h5UHG1EwRWay+cGhY2 sz9IcZ7O0sB7zKwkjSfAsW2OL4VxTTEDumqnvZ4QlGMQphyHwJuvJYj9uH40hrj9ypWz lC0xoPaKkf9vZNE271gZfq+AWVToGTo3fQ8H+Msv+KqcfjhDEi39xg5WDc3mfqOjRuWA sSw9Xq8tlYGnPAtGevyBTNkOFMaHSdXEwrsmQaEZq/lh+ctBWIpb+9TOD9/ab+/QQ8HM xL+eMPSM02jFEwfm1P+f1p84pS8dL7UQhCuiFeH4X0VWCytcYUGDX9egDJjFyHU0Ooqk Kqcw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=wbuuGwLQ; dkim=neutral (no key) header.i=@suse.cz; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g17si797549pgk.528.2021.10.14.11.27.27; Thu, 14 Oct 2021 11:27:40 -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=@suse.cz header.s=susede2_rsa header.b=wbuuGwLQ; dkim=neutral (no key) header.i=@suse.cz; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231546AbhJNPkY (ORCPT + 99 others); Thu, 14 Oct 2021 11:40:24 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:50958 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230389AbhJNPkV (ORCPT ); Thu, 14 Oct 2021 11:40:21 -0400 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 57BA02197C; Thu, 14 Oct 2021 15:38:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1634225895; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GxLH0z7C+H9xHqrBRI+kBoQatoT6Befch1xXUBOMRvk=; b=wbuuGwLQVKd5RGDVEuiKlyGa4uSDIPQIj3iTwLLGyLMsj1FIXqLCyC4SWZfKz9Y52rxVWX jXSR6UdtN2SQhnvuIhAzM/7S110oBFVEVXWBPV3vnUO19qOAd4fui4K9xCBADnjX1NIDKO kouz2fDzruRykAWYJYRg1X9KxXcNFmY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1634225895; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GxLH0z7C+H9xHqrBRI+kBoQatoT6Befch1xXUBOMRvk=; b=HWNic10Z5eyZjDRof2nMzOceoNhhVXTEui8u/gJbvPKg83g3XcTyKgV28mYXRyPhO4MWOj nV62pu27waEV4ABA== 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 2A73E13D9F; Thu, 14 Oct 2021 15:38:15 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id BIG+CedOaGEwHwAAMHmgww (envelope-from ); Thu, 14 Oct 2021 15:38:15 +0000 Message-ID: <76454f39-8e41-e757-3a71-c85303c6257e@suse.cz> Date: Thu, 14 Oct 2021 17:38:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH 6/8] mm/vmscan: Centralise timeout values for reclaim_throttle Content-Language: en-US To: Mel Gorman , Linux-MM Cc: NeilBrown , Theodore Ts'o , Andreas Dilger , "Darrick J . Wong" , Matthew Wilcox , Michal Hocko , Dave Chinner , Rik van Riel , Johannes Weiner , Jonathan Corbet , Linux-fsdevel , LKML References: <20211008135332.19567-1-mgorman@techsingularity.net> <20211008135332.19567-7-mgorman@techsingularity.net> From: Vlastimil Babka In-Reply-To: <20211008135332.19567-7-mgorman@techsingularity.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/8/21 15:53, Mel Gorman wrote: > Neil Brown raised concerns about callers of reclaim_throttle specifying > a timeout value. The original timeout values to congestion_wait() were > probably pulled out of thin air or copy&pasted from somewhere else. > This patch centralises the timeout values and selects a timeout based > on the reason for reclaim throttling. These figures are also pulled > out of the same thin air but better values may be derived > > Running a workload that is throttling for inappropriate periods > and tracing mm_vmscan_throttled can be used to pick a more appropriate > value. Excessive throttling would pick a lower timeout where as > excessive CPU usage in reclaim context would select a larger timeout. > Ideally a large value would always be used and the wakeups would > occur before a timeout but that requires careful testing. > > Signed-off-by: Mel Gorman Acked-by: Vlastimil Babka