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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 51F2BC2D0F9 for ; Wed, 13 May 2020 07:16:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2219D206D6 for ; Wed, 13 May 2020 07:16:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2219D206D6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AC6FB90010A; Wed, 13 May 2020 03:16:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A77F89000F3; Wed, 13 May 2020 03:16:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 98CD190010A; Wed, 13 May 2020 03:16:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0236.hostedemail.com [216.40.44.236]) by kanga.kvack.org (Postfix) with ESMTP id 7F7E29000F3 for ; Wed, 13 May 2020 03:16:42 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 33F7E2496 for ; Wed, 13 May 2020 07:16:42 +0000 (UTC) X-FDA: 76810838244.24.feast83_1d608069f8e15 X-HE-Tag: feast83_1d608069f8e15 X-Filterd-Recvd-Size: 3615 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Wed, 13 May 2020 07:16:41 +0000 (UTC) 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 B8867B1DD; Wed, 13 May 2020 07:16:42 +0000 (UTC) From: NeilBrown To: Jan Kara Date: Wed, 13 May 2020 17:16:32 +1000 Cc: Andrew Morton , Michal Hocko , linux-mm@kvack.org, linux-nfs@vger.kernel.org, LKML , Christoph Hellwig Subject: Re: [PATCH 1/2 V3] MM: replace PF_LESS_THROTTLE with PF_LOCAL_THROTTLE In-Reply-To: <20200422124600.GH8775@quack2.suse.cz> References: <87tv2b7q72.fsf@notabene.neil.brown.name> <87v9miydai.fsf@notabene.neil.brown.name> <87ftdgw58w.fsf@notabene.neil.brown.name> <87wo6gs26e.fsf@notabene.neil.brown.name> <87tv1ks24t.fsf@notabene.neil.brown.name> <20200416151906.GQ23739@quack2.suse.cz> <87zhb5r30c.fsf@notabene.neil.brown.name> <20200422124600.GH8775@quack2.suse.cz> Message-ID: <871rnob8z3.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" 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: --=-=-= Content-Type: text/plain I thought about this some more and come up with another "simple" approach that didn't require me understanding too much code, but does - I think - address your concerns. I've changed the heuristic to avoid any throttling on PF_LOCAL_THROTTLE task if: - the global dirty count is below the global free-run threshold. The code did this already. - (or) the per-wb dirty count is below the per-wb free-run threshold. This is the change. This means that: - in a steady stated, all bdis will be throttled based on their (steady state) throughput, which is equally appropriate for PF_LOCAL_THROTTLE tasks. - a PF_LOCAL_THROTTLE task will never be *completely* blocked by dirty pages queued for other devices. This means no deadlock, and that is the primary purpose of PF_LOCAL_THROTTLE. - when writes through the PF_LOCAL_THROTTLE task start up from idle - when there is no current throughput estimate - the PF_LOCAL_THROTTLE can be expected to get a fair share of the available memory, just as much as any other writer. This was the possible problem with treating PF_LOCAL_THROTTLE just like BDI_CAP_STRICTLIMIT. So I think this is a good solution. Thoughts? Patches follow - I've address the comment formatting issue. Thanks, NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAl67ntAACgkQOeye3VZi gbkPqRAAtxj9x2Nnc8sDId77c2gR7zMDpFPEY6g07dqJpWw0yBr6dWPypKbUpsso 4kqJpJDxKpM/zo6ysnkDPJJmNmgIS5n6s3vQCsumP7+TF3PpnMtAqG2GnvxVOLkN VPIb4HCghdI0mGS9xeR1OBPHsK8I0HvHg0CGWAo5rCCICRmDAQXCYL5QdGqfLuxj B/55yI4jzKfH6OaArJrrKWvWVdI825oGSn/bdffz/GighPP1QdLbNz4iWS5ab43O 0tR4m9JjGQIB7RjxnNXp0knc3+2hVqKY6dallTpOpn4fE0n7TeSFu7lvI6wRL7F/ OKLBlY9ca7jeIOcrCwBan5GFOh9Ou0IFvX41ehrFEFUc6dTb4836b8T9HunKP95d dwL3v1gpFI06IZwb+K0YGrf9MWDSZQeZ/tPyHM2VDFb2Jl3hx+3aVxhhY9bgPtjZ Mf3cbYBiGWU+xoZwPYKKw4ghNgJDTOZd0ohTTfM0c9TuGp7+NZUtU/3/9J9/Cw91 P4ZNnN4AyW20Jh2ucfACOesx3LorjbvXIwRPaJJ8hLHQVUZ66RJoIs3QJ+5lpbQc pO6kQ8uTynnSHa5Gt39CnQVjAz2AoXsrU/sKFRQ/HAZd8hyzDXrgnn+EAdy6KwO1 EF92Wa5AIVLDF4qfCuYsLDH4gAUrtRxFqoER4NWMxIJtX8nrChU= =vbJX -----END PGP SIGNATURE----- --=-=-=--