Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2040962pxb; Fri, 17 Sep 2021 00:17:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxfHBknzHSS8RwgTC3y2aGWE5H3A9tBjNEf9uptNOjEIX60Hu/1MEHjGKXvdB+6fiKIqzUB X-Received: by 2002:a5d:8894:: with SMTP id d20mr7325798ioo.4.1631863046856; Fri, 17 Sep 2021 00:17:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631863046; cv=none; d=google.com; s=arc-20160816; b=WfxNTrge91efa91gzTKQkIfzrR9T1p5OITjz17z602g9CoxOn4/rwGA3i06TEktIgF ulnb883apsRgGN2TVTbk1MSYovejj+ENFRNUgI4lyJ2O5z3XYfm+dXqqxuDS+kMY64IM YoUwzNNoV954NbbA7mToMRZ+TqC+NcEFoKspL5yGpBtimtzXFydMpbHWjo1mYreJD5Ob /niGcAkWv/9PNesTeSgLxO9r8bfJA9WnMkIuIqS2H3+DX7+B7xVmFrl7TsIYvzmuSb1x 3w3ERKfRYpHgb39qlpOXqucP8uCSFZU6vhAPchlRZC5G72uZQfDkfcYX4/A+D51lrt6v RDmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:references:in-reply-to:subject :cc:to:from:mime-version:content-transfer-encoding:dkim-signature :dkim-signature; bh=fUML7PP2cwKhFn9IzXhNLUrnTUVcJXoS96ewZU1uWd4=; b=qA9CXzgGfCyujcxF5G/WX88il6mgmUu4MEvXsGwbLybQAGr3ohG6ejVpuIMIDABCab 62rZW7QVLJzCj3qH46CAJGAbDO1KD/H61Gu2OWnbPXI6zMXuw002EdMt7LMi8w/G7J+C QBfH+6xnbo8ghN7hLoONWe1rh1QQKrYrkLEU2Ry6AFYG/XebaaWesucKIRvVXg0vkZfv s3pPC+SvLOPWeQth7VELuvjrAimbn0wLBg9UWiYUy/DE4Qnsc3D4y730LDJX3iLq5WUh dMIkLi9sSxUzwyevMWcQ4SuZ/emiKl3ChoxBqbdgPBJ1RdI2AgVdaglmxGLXs8LpYZzT av0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=jXq3fACJ; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n9si5936931ilk.2.2021.09.17.00.17.10; Fri, 17 Sep 2021 00:17:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-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.de header.s=susede2_rsa header.b=jXq3fACJ; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240788AbhIPWOt (ORCPT + 99 others); Thu, 16 Sep 2021 18:14:49 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:54872 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240764AbhIPWOs (ORCPT ); Thu, 16 Sep 2021 18:14:48 -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 D597F22285; Thu, 16 Sep 2021 22:13:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1631830405; 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=fUML7PP2cwKhFn9IzXhNLUrnTUVcJXoS96ewZU1uWd4=; b=jXq3fACJglbXO8ZZxnEEMQ+MUPWIjZYeP9OWVMQcOLpTCitAL/GY0hB3ikpZqLry9QOXDj ZRrPGSLgWi+Y6HeNGhcNrGJGBweWKtIOvbUo2E/PYEVdhNesAL6oSHskkTyze7963m/w7v FapF8aEecdCetxL/vyAtSFplWCBT8aI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1631830405; 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=fUML7PP2cwKhFn9IzXhNLUrnTUVcJXoS96ewZU1uWd4=; b=tYmy1+ayRfKGCMEtC5l9akiHOlDJJKFM6kSmG2YO8aDY/SdACek6JZkZDMbN7tSZ+4Wr23 jXJfi3+TQ02lBADg== 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 35C2013D6D; Thu, 16 Sep 2021 22:13:21 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id uyMeOYHBQ2GwUwAAMHmgww (envelope-from ); Thu, 16 Sep 2021 22:13:21 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "NeilBrown" To: "Michal Hocko" Cc: "Andrew Morton" , "Theodore Ts'o" , "Andreas Dilger" , "Darrick J. Wong" , "Matthew Wilcox" , "Mel Gorman" , linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/6] MM: annotate congestion_wait() and wait_iff_congested() as ineffective. In-reply-to: References: <163157808321.13293.486682642188075090.stgit@noble.brown>, <163157838437.13293.15392955714346973750.stgit@noble.brown>, Date: Fri, 17 Sep 2021 08:13:19 +1000 Message-id: <163183039931.3992.6407941879351179168@noble.neil.brown.name> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed, 15 Sep 2021, Michal Hocko wrote: > On Tue 14-09-21 10:13:04, Neil Brown wrote: > > Only 4 subsystems call set_bdi_congested() or clear_bdi_congested(): > > block/pktcdvd, fs/ceph fs/fuse fs/nfs > >=20 > > It may make sense to use congestion_wait() or wait_iff_congested() > > within these subsystems, but they have no value outside of these. > >=20 > > Add documentation comments to these functions to discourage further use. >=20 > This is an unfortunate state. The MM layer still relies on the API. > While adding a documentation to clarify the current status can stop more > usage I am wondering what is a real alternative. My experience tells me > that a lack of real alternative will lead to new creative ways of doing > things instead. That is a valid concern. Discouraging the use of an interface without providing a clear alternative risks people doing worse things. At lease if people continue to use congestion_wait(), then we will be able to find those uses when we are able to provide a better approach. I'll drop this patch. Thanks, NeilBrown > =20 > > Signed-off-by: NeilBrown > > --- > > include/linux/backing-dev.h | 7 +++++++ > > mm/backing-dev.c | 9 +++++++++ > > 2 files changed, 16 insertions(+) > >=20 > > diff --git a/include/linux/backing-dev.h b/include/linux/backing-dev.h > > index ac7f231b8825..cc9513840351 100644 > > --- a/include/linux/backing-dev.h > > +++ b/include/linux/backing-dev.h > > @@ -153,6 +153,13 @@ static inline int wb_congested(struct bdi_writeback = *wb, int cong_bits) > > return wb->congested & cong_bits; > > } > > =20 > > +/* NOTE congestion_wait() and wait_iff_congested() are > > + * largely useless except as documentation. > > + * congestion_wait() will (almost) always wait for the given timeout. > > + * wait_iff_congested() will (almost) never wait, but will call > > + * cond_resched(). > > + * Were possible an alternative waiting strategy should be found. > > + */ > > long congestion_wait(int sync, long timeout); > > long wait_iff_congested(int sync, long timeout); > > =20 > > diff --git a/mm/backing-dev.c b/mm/backing-dev.c > > index 4a9d4e27d0d9..53472ab38796 100644 > > --- a/mm/backing-dev.c > > +++ b/mm/backing-dev.c > > @@ -1023,6 +1023,11 @@ EXPORT_SYMBOL(set_bdi_congested); > > * Waits for up to @timeout jiffies for a backing_dev (any backing_dev) = to exit > > * write congestion. If no backing_devs are congested then just wait fo= r the > > * next write to be completed. > > + * > > + * NOTE: in the current implementation, hardly any backing_devs are ever > > + * marked as congested, and write-completion is rarely reported (see cal= ls > > + * to clear_bdi_congested). So this should not be assumed to ever wake = before > > + * the timeout. > > */ > > long congestion_wait(int sync, long timeout) > > { > > @@ -1054,6 +1059,10 @@ EXPORT_SYMBOL(congestion_wait); > > * The return value is 0 if the sleep is for the full timeout. Otherwise, > > * it is the number of jiffies that were still remaining when the functi= on > > * returned. return_value =3D=3D timeout implies the function did not sl= eep. > > + * > > + * NOTE: in the current implementation, hardly any backing_devs are ever > > + * marked as congested, and write-completion is rarely reported (see cal= ls > > + * to clear_bdi_congested). So this should not be assumed to sleep at a= ll. > > */ > > long wait_iff_congested(int sync, long timeout) > > { > >=20 >=20 > --=20 > Michal Hocko > SUSE Labs >=20 >=20