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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55AC6C77B7A for ; Tue, 30 May 2023 18:18:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 710F1900002; Tue, 30 May 2023 14:18:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CA4F6B0074; Tue, 30 May 2023 14:18:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5875E900002; Tue, 30 May 2023 14:18:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 4619C6B0072 for ; Tue, 30 May 2023 14:18:57 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 14ACB1402DC for ; Tue, 30 May 2023 18:18:57 +0000 (UTC) X-FDA: 80847732714.21.ED9C4C2 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf20.hostedemail.com (Postfix) with ESMTP id 4D23C1C0023 for ; Tue, 30 May 2023 18:18:55 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HbsjnUKj; spf=pass (imf20.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685470735; a=rsa-sha256; cv=none; b=t1y+Xp0cIjXoBFvKHzW7ztQv4IjzS7oGQSkXYeE6roRK47L2/XTWMPFXJxcD7bXafRC9Xa CDEn9bIwRekzw+1HXVZhms9N0ye17nXoQmQEQwr/ZSsL7d/1DeiNHzrMKh69zoNJK7m+AL AT5XN+vt7VXEDrBA15zDjRhzCbCInto= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HbsjnUKj; spf=pass (imf20.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1685470735; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=55uQB3ZS0vFz2r/66KK15sdhuv6or2xOWHnW8DUuJSM=; b=lq2LO/T/NtT+C+asQacM4dG/gWUtNFKwykjrVGw43gsZqgscy/DqVB6LE1Cem/3QV2kmBT 2+veorCPkIaHFZ7xaDuxUhX9rz76Du+iw5SnjRhxckQVEObBMHoSmlSykFWiqFpjA87jXb 1SyGDdz0QZkJRslZ7C07+dY48PeqVeI= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4EA6561348; Tue, 30 May 2023 18:18:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 637D9C4339C; Tue, 30 May 2023 18:18:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685470733; bh=GSoJuOKRdY+uRAsGoUp8M6lD7U0u8mQi49JYAbktU9U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HbsjnUKjcjDwjDBgQ5g4mt2ee+gpdY2yXecyHxE/5hujI30cFSqea0ycWzHcL81rT Mfr3M+KeDBwyVG8wGbmB3kBb3lzVPSTnZXtLdj2NQG+nbccDO2IXHWGlQIBkUOB9au oAW2PbOv2XKJzGjYmq07qE4hKm4OSZzNn7qitSAtF3cZ3aJQfQdmfmtG8FUfqSIUWV eIadpWXL3xmWRS3aZekd7viWkoV6I04WuQbWW2EE+iCds6XzUFPe3Cr7yFp+MGoA/O 8ZK/DKacTit9g01Bph9xXyfJSQUxoaz0C2XJySRvgeSj0hf2s50rv3Q98U0tmOlXmd JVjlNbIm8Rh5Q== Date: Tue, 30 May 2023 11:18:51 -0700 From: Chris Li To: Johannes Weiner Cc: Domenico Cerasuolo , linux-mm@kvack.org, linux-kernel@vger.kernel.org, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, yosryahmed@google.com, kernel-team@fb.com Subject: Re: [PATCH] mm: zswap: shrink until can accept Message-ID: References: <20230524065051.6328-1-cerasuolodomenico@gmail.com> <20230530041341.GB84971@cmpxchg.org> <20230530155519.GB97194@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230530155519.GB97194@cmpxchg.org> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 4D23C1C0023 X-Stat-Signature: ahzdk9mu5thfp9uwiouscpm1zoeo4xoo X-Rspam-User: X-HE-Tag: 1685470735-753542 X-HE-Meta: U2FsdGVkX18lIxkWur/EWXZ8mn5vcKJtN1Qkh/AAClitKzZtf+UfeknId7IeQG0JJm0IAv2x3N1uSFd7439hvGwiGqlwPgp7ar9TZBEZMOUE9VU1/cgcmF/cqOLJKqbGQDHg9j8XqmoWdHQsx8NQleR1JCcrAWkEfVBy6LpAKP9cCIbKKEEbbvM1TG+3ZoUNI7jV4OWgkSHAqthSSRExu0OQvQkMDLNzKjF07cAW4HU/jV9AkTmrftfD7B5uouCWghpia5Lpw/xwNz6V+KIss9OdkSLO8sdlSn1Y1xVhla864DHI0R6PEJw3aKsKaPQgyTUAopegR4ZKkk72qhAwtDa2OMzRTEs1WxfbM8yGTVh0RzpyYHoNq/rmjqUxIOYzS4bZ/1lW1f44Uso4xZjxEoDiqMlXHzUxv4+8EMQaEkYIZkVuCaWIBw7E0WyxAArLupMqTrapvVMIBtdHKSXJc1svQXRFQ3IBlFkZpSdzxJMygQwjjgcT36yQ+CEWjShagAOV4MgmgCgQTq0jiAmrQFPfJ7bpqmrjiajaZCsAhWxpUrURpuvPse62SuWq6NY0h1PH3loq2OiTnjmS0mH9qBmOx3lu+VoEQLXAOJsp9wrN/jxQDnnjNj/6cwwRdbMbdUUPuVDVkcFFH0vZvua+wDywni0dx3n0ypueyZoVKN3YjJHy7JL7jfFYG9WdIWuAzTpp17uaDW/IUAKblCLVZCjVMS4TR9BUsPwbR7k4gxSATigZIizM2W0LTzyKSJ5LobGRt5yx9UtQcVi3bRK0xJjH69FaNchYCam+X7ZfVAG7MJ0pOToWb+e8JHls6cRIT3ZWqRGJtossV6xrU7nAkGKwGlrHokBgtnGEW9ZRzUzjVSfmz4Tu3EVG/mI1BtJC2DBleeqcGObxbC6gricnjAjlitaODtHOiIb0w4HYZ7/W196M95seamDWJZmXgYovyD1aN5uSI5mfOegCVWr EBcg3Fwf Z7IaaMuOD6C+vsFZwMDMQrZifpUwGWNqq21O03TGKbZd0rFxpERFObmwFzpJ5w8vdotuAyx94k48+BmM29slSOEtci4RUQGVRTuhzW+ERo7zCjsVcARAkfklw/fqQNEskFOHWO75pPHUSHX6gR6SELhpj9HKHBqa/79Y4PmFA3gCIGJwFCq14+g3sE7zSAEtyLcdHrvvwyMhuo+XwcE5ZX0UIT1NyAY+8eiQmTAW8+GldSMSCvnsdGymviQ== 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 Tue, May 30, 2023 at 11:55:19AM -0400, Johannes Weiner wrote: > On Tue, May 30, 2023 at 07:51:23AM -0700, Chris Li wrote: > > Thanks for pointing out -ENOMEM shouldn't be persistent. > > Points taken. > > > > The original point of not retrying the persistent error > > still holds. > > Okay, but what persistent errors are you referring to? Maybe ENOMEM is a bad example. How about if the swap device just went bad and can't complete new IO writes? > Aside from -ENOMEM, writeback_entry will fail on concurrent swap > invalidation or a racing swapin fault. In both cases we should > absolutely keep trying other entries until the goal is met. How about a narrower fix recognizing those error cases and making the inner loop continue in those errors? > > > Should it be fixed before merging this patch? I don't think the > > > ordering matters. Right now the -ENOMEM case invokes OOM, so it isn't > > > really persistent either. Retrying a few times in that case certainly > > > doesn't seem to make things worse. > > > > If you already know the error is persistent, retrying is wasting > > CPU. It can pertancial hold locks during the retry, which can > > slow someone else down. > > That's a bit of a truism. How does this pertain to the zswap reclaim > situation? See the above narrower fix alternative. > > > > > > As I was writing to Yosry, the differentiation would be a great improvement > > > > > here, I just have a patch set in the queue that moves the inner reclaim loop > > > > > from the zpool driver up to zswap. With that, updating the error handling > > > > > would be more convenient as it would be done in one place instead of three.i > > > > > > > > This has tricky complications as well. The current shrink interface > > > > doesn't support continuing from the previous error position. If you want > > > > to avoid a repeat attempt if the page has a writeback error, you kinda > > > > of need a way to skip that page. > > > > > > A page that fails to reclaim is put back to the tail of the LRU, so > > > for all intents and purposes it will be skipped. In the rare and > > > > Do you mean the page is treated as hot again? > > > > Wouldn't that be undesirable from the app's point of view? > > That's current backend LRU behavior. Is it optimal? That's certainly > debatable. But it's tangential to this patch. The point is that > capping retries to a fixed number of failures works correctly as a > safety precaution and introduces no (new) undesirable behavior. > > It's entirely moot once we refactor the backend page LRU to the zswap > entry LRU. The only time we'll fail to reclaim an entry is if we race > with something already freeing it, so it doesn't really matter where > we put it. Agree with you there. A bit side tracked. > > > extreme case where it's the only page left on the list, I again don't > > > see how retrying a few times will make the situation worse. > > > > > > In practice, IMO there is little upside in trying to be more > > > discerning about the error codes. Simple seems better here. > > > > Just trying to think about what should be the precise loop termination > > condition here. > > > > I still feel blindly trying a few times is a very imprecise condition. > > The precise termination condition is when can_accept() returns true > again. The safety cap is only added as precaution to avoid infinite > loops if something goes wrong or unexpected, now or in the future. In my mind, that statement already suggests can_accept() is not *precise*, considering the avoid infinite loop. e.g. Do we know what is the optimal cap value and why that value is optical? Putting the definition of precise aside, I do see the unconditional retry can have unwanted effects. Chris