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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF330C433EF for ; Sat, 6 Nov 2021 21:20:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6648C611AE for ; Sat, 6 Nov 2021 21:20:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6648C611AE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id DE3406B006C; Sat, 6 Nov 2021 17:20:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D92066B00FF; Sat, 6 Nov 2021 17:20:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C34B46B0100; Sat, 6 Nov 2021 17:20:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0153.hostedemail.com [216.40.44.153]) by kanga.kvack.org (Postfix) with ESMTP id B12B06B006C for ; Sat, 6 Nov 2021 17:20:12 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 6A77A76B63 for ; Sat, 6 Nov 2021 21:20:12 +0000 (UTC) X-FDA: 78779773464.13.5B23FB3 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf20.hostedemail.com (Postfix) with ESMTP id 6B558D000641 for ; Sat, 6 Nov 2021 21:20:02 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 3E99060240; Sat, 6 Nov 2021 21:20:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1636233609; bh=nNadFUWRbcC3kNmm5hW/iEEJPZbJezLbRcMqTbl9l6A=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TFFChLZx/tfVHwMvwfsfY5N3g7+hOE1nMSOtwzkiO8VFERdyCjxwvK+QcXUUHvz0/ 4sPJW0TRDW3Svbq8dY9EapGguaEvJ/WR1abYOgfPfF1Tgh+B+1SSX19nEiRhMP9sDW da2AOJ1pYcMEEHbBbYG/WTi/Q/PhT9g59vwhlh+g= Date: Sat, 6 Nov 2021 14:20:07 -0700 From: Andrew Morton To: Vlastimil Babka Cc: Linus Torvalds , Matthew Wilcox , Andreas Dilger , Jonathan Corbet , Dave Chinner , "Darrick J. Wong" , Johannes Weiner , Linux-MM , Mel Gorman , Michal Hocko , mm-commits@vger.kernel.org, Neil Brown , Rik van Riel , "Theodore Ts'o" Subject: Re: [patch 149/262] mm/vmscan: throttle reclaim until some writeback completes if congested Message-Id: <20211106142007.6996480f2ac52b96c273ecf5@linux-foundation.org> In-Reply-To: References: <20211105133408.cccbb98b71a77d5e8430aba1@linux-foundation.org> <20211105204225.iIh99P9cn%akpm@linux-foundation.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 6B558D000641 X-Stat-Signature: oc9qzeh8k5gof6q6ygc81triwfjyebmu Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=TFFChLZx; dmarc=none; spf=pass (imf20.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-HE-Tag: 1636233602-487624 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 Sat, 6 Nov 2021 22:13:34 +0100 Vlastimil Babka wrote: > On 11/6/21 22:12, Linus Torvalds wrote: > > On Sat, Nov 6, 2021 at 1:49 PM Linus Torvalds > > wrote: > >> > >> This workflow can result in more conflicts for me than what Andrew > >> used to do ("send against current linus tip"), but it means that when > >> conflicts happen, they get all the merge resolution help that git > >> gives you, and hopefully what gets tested (over the months that it can > >> be in -mm) is closer to what gets sent to me. > > > > .. and resolving the conflicts (none of which looked bad), I think > > that part of the resolution ends up doing very similar things to your > > fixup patch. > > If this needed resolution, didn't the resolution exist in -next already? Yes, but I had it queued after linux-next.patch so it got lost in the unholy mess that linux-next becomes during the merge window. I'm still figuring this out. In retrospect I should have moved this patch "mm/vmscan: throttle reclaim until some writeback completes if congested" to the post-linux-next section weeks ago, then waited for the prerequisites to be merged into mainline. That way the unaltered, tested patch would have smoothly slotted in late in the merge window.