Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp932000ybb; Fri, 3 Apr 2020 14:41:31 -0700 (PDT) X-Google-Smtp-Source: APiQypLRQAieQfEleyWqoD1b+NZ4LwufC1natJdr993W20yi2JT8FPRZVuBTbmlar5+UKg/L8Wvn X-Received: by 2002:aca:f582:: with SMTP id t124mr4822258oih.17.1585950090826; Fri, 03 Apr 2020 14:41:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585950090; cv=none; d=google.com; s=arc-20160816; b=Fiw2I9IrE9T1i/OuaSDQl5LNavIKB0f7bjOmKWuJdTBBjVORnJ8x2nqKayogPeAYZH ZzYgFZow2yu82YB4Wr8AY7pXuYjHQvgsKliGiH3QUFO7V0G93oxqD0O7eaKyht9A4/fu wm+ovhFHf996ZCHts35s6Rncf6ZDibBE5vA7e4VddEHR6CrOUoYeSiuU23CWQ4JAUIno FoffebEvl2lNUpIV66rQv/mtlE2G3m2YmI8glr+x81swAj1qxTY4fr0TwWqbhEj6Ms71 qKFttvp68Kaefjq874jljHJG2kiQ/MepMP5xaSauzcWHHWeSJZR/iHXByYn6H0Wh2LYF AmiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:references :in-reply-to:subject:cc:date:to:from; bh=Ttg6EUHtzUcysDdrv4baiTERWeYhl01mmTTorwofgJw=; b=JMg3BZnyfo5lf0CpRgmvWs78to1CYQILTHVRDp/hILL8ARFONG9PH9jBxVCu2FW8qS cMxarqbfrGpaJBPimeBTcbkIafnlHQYp3HY6o5RvmNl2qJl/i5FROHnP0jnBdz0eUhNx jayfRQIwWHNtHo3+otShpq7Bp3rBdAv7Wyfrvyq2iTmKoZ5m5RbiVJ41MwW+jI7DrfFn Vc8bz9SQ02gz0PDmGAE3NFSPiMjKbC+SVPyZFU/zjba3y3nRFb6eHAFwjunJmPIOc3RS lKquQbHZXJWEHkTjhR4Cw1e1k0mVs/jok+xND47aoO0ja2btSajAKQ9PEEbtP6b3l9nH In6Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 64si4351893otn.173.2020.04.03.14.41.17; Fri, 03 Apr 2020 14:41:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728249AbgDCVk2 (ORCPT + 99 others); Fri, 3 Apr 2020 17:40:28 -0400 Received: from mx2.suse.de ([195.135.220.15]:47792 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726460AbgDCVk1 (ORCPT ); Fri, 3 Apr 2020 17:40:27 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 511B1ACED; Fri, 3 Apr 2020 21:40:25 +0000 (UTC) From: NeilBrown To: Michal Hocko Date: Sat, 04 Apr 2020 08:40:17 +1100 Cc: Trond Myklebust , "Anna.Schumaker\@Netapp.com" , Andrew Morton , Jan Kara , linux-mm@kvack.org, linux-nfs@vger.kernel.org, LKML Subject: Re: [PATCH 1/2] MM: replace PF_LESS_THROTTLE with PF_LOCAL_THROTTLE In-Reply-To: <20200403151534.GG22681@dhcp22.suse.cz> References: <87tv2b7q72.fsf@notabene.neil.brown.name> <87v9miydai.fsf@notabene.neil.brown.name> <87sghmyd8v.fsf@notabene.neil.brown.name> <20200403151534.GG22681@dhcp22.suse.cz> Message-ID: <878sjcxn7i.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, Apr 03 2020, Michal Hocko wrote: > On Thu 02-04-20 10:53:20, Neil Brown wrote: >>=20 >> PF_LESS_THROTTLE exists for loop-back nfsd, and a similar need in the >> loop block driver, where a daemon needs to write to one bdi in >> order to free up writes queued to another bdi. >>=20 >> The daemon sets PF_LESS_THROTTLE and gets a larger allowance of dirty >> pages, so that it can still dirty pages after other processses have been >> throttled. >>=20 >> This approach was designed when all threads were blocked equally, >> independently on which device they were writing to, or how fast it was. >> Since that time the writeback algorithm has changed substantially with >> different threads getting different allowances based on non-trivial >> heuristics. This means the simple "add 25%" heuristic is no longer >> reliable. >>=20 >> This patch changes the heuristic to ignore the global limits and >> consider only the limit relevant to the bdi being written to. This >> approach is already available for BDI_CAP_STRICTLIMIT users (fuse) and >> should not introduce surprises. This has the desired result of >> protecting the task from the consequences of large amounts of dirty data >> queued for other devices. > > While I understand that you want to have per bdi throttling for those > "special" files I am still missing how this is going to provide the > additional room that the additnal 25% gave them previously. I might > misremember or things have changed (what you mention as non-trivial > heuristics) but PF_LESS_THROTTLE really needed that room to guarantee a > forward progress. Care to expan some more on how this is handled now? > Maybe we do not need it anymore but calling that out explicitly would be > really helpful. The 25% was a means to an end, not an end in itself. The problem is that the NFS server needs to be able to write to the backing filesystem when the dirty memory limits have been reached by being totally consumed by dirty pages on the NFS filesystem. The 25% was just a way of giving an allowance of dirty pages to nfsd that could not be consumed by processes writing to an NFS filesystem. i.e. it doesn't need 25% MORE, it needs 25% PRIVATELY. Actually it only really needs 1 page privately, but a few pages give better throughput and 25% seemed like a good idea at the time. per-bdi throttling focuses on the "PRIVATELY" (the important bit) and de-emphasises the 25% (the irrelevant detail). Thanks, NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAl6HrUIACgkQOeye3VZi gbmw9RAAqwZBhuc0mji+8z77xXmpuIRdxZtz5yjKjpurelYayyVuKTquw4+aO+ib 7ragLhHuVIc9JV15Zu4vrbajDiy7uQhJdISTNE4b+JZ9FblQ9+2bqBYJwu8GZ+sn an6XpC3bWHKroN5m+eJSeArrhsT8uXbMUYqx7MJVGXzOAwfxzxOKXRQnGsRlgUZp DLs4OtI0cPbkQ5+3FBNkhznS29o33dRVLiuiVhBflHek5eHAFctq5zeOx9cDlGvt d7Dk/XmXHqR4952XLCCCxCk37FxiXqiiQd4xs/ZbTbkRhd4RBLFBahirTHAbbFEu Ntrso2lvM3fnan7JmuO+vanChCCZ+Ggactvkrdz4CvmGouJ1Ln5XO1h1iX00NBvM 5GxDvL9DSBlINl4cdN6xaVjQOhWSNoRejOG19VF4pn2opWJjB9KXEDtzc5qDwtK7 Eq1FlzEQ8EwJB7wK5Hyv3VmrICQU96h+eh+jBqnpaxq3Fz3Trojdgh3VcY25P1T8 RXOfD7wGdvYk2FZhjxBOQHcikAw3jl5LGyI77VAQf3eiROphl0+Q1kLp9Ugniaso 0tna59vfaEdFeZogPtQ7piy91l1bvtj1SoP7BODnI/PQ8hEyCGaA9IFKg0dpsTVW k/7TZMXpTi866D9ct+/sLG2Lc6u7QKwhclHSAh2Waw/6m7d0wlg= =XeBp -----END PGP SIGNATURE----- --=-=-=--