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 5FCE7C77B73 for ; Tue, 30 May 2023 15:55:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 01A57280002; Tue, 30 May 2023 11:55:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F0CA9900002; Tue, 30 May 2023 11:55:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DD426280002; Tue, 30 May 2023 11:55:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id CAB9F900002 for ; Tue, 30 May 2023 11:55:23 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 813CF140211 for ; Tue, 30 May 2023 15:55:23 +0000 (UTC) X-FDA: 80847370926.12.8CC3F8A Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) by imf30.hostedemail.com (Postfix) with ESMTP id 47E1680010 for ; Tue, 30 May 2023 15:55:21 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=cmpxchg-org.20221208.gappssmtp.com header.s=20221208 header.b=sUQAliy2; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf30.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.169 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1685462121; 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=vwWNOMoHZ+UIdNSWemfCGD87I++1r7zOSkWu1kWsMYM=; b=zUYB3ef0sU0MxcqsxT8uATgDgRReIBPOPdKSCF32f5UL2GCw1qf6INrftfF+MMS9b56Nwk Efo84rtHtqQ3Ais3p7x8pzg9Qh1c9vvPwuzuLDNnq3H6rqIwvOIWeIXF2shtcLpuMoWhZX Bm3KM1CntEiWnXunHCwFynxNBYqf6HM= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=cmpxchg-org.20221208.gappssmtp.com header.s=20221208 header.b=sUQAliy2; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf30.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.169 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685462121; a=rsa-sha256; cv=none; b=aa+H4upa0JhVE6WDF2FFrCD+IAjiHeNWUz8n4fRLCnX3fbqdviwzM20fRPN5ZmJAVBLTNx 4aAQzQ32f+UVRCrT2qMkbe+Y8HdnRfkf2pSMi+UkPgPWwLX8SHKCpDhks5tcxcyQPnWgZW XQv30A8ZDRAf5AWllyWwlEv1A2QWzco= Received: by mail-qk1-f169.google.com with SMTP id af79cd13be357-75b2a2bf757so274033485a.2 for ; Tue, 30 May 2023 08:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20221208.gappssmtp.com; s=20221208; t=1685462120; x=1688054120; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=vwWNOMoHZ+UIdNSWemfCGD87I++1r7zOSkWu1kWsMYM=; b=sUQAliy2CXREXRDfURy5ytT1mp6Z2MVRnyOpeymtwMw7RdoAiL5YRa0MmQLydAuXqU vgbFfj0rElE0lwudazbOwScQSfuVCq2SaymmgO86qe9hKMw/ieoDY+53ZOK4AQm2lRhQ gYx9zKeUHwLdwVXr5FQTsRIifWNNqn7belm/2dqcnfyP1bxQO5ZVVRfGufqk9ZtKuStA CbgGI4y5OkhmkAFo/a3fttbFCkE8XlTJ0oYoGcdxnxkk27aBVC3lNsNQQjzFVYZuJM3y fhCQ8OvDtdubeZwbvOHhiNY23yo7i01SdMIfeb9L+njLvOQ+eN54eyTvajzX9aoRpz92 O9Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685462120; x=1688054120; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vwWNOMoHZ+UIdNSWemfCGD87I++1r7zOSkWu1kWsMYM=; b=ZSWUnWwFALcEpaQdXlhq9kF6g5Bb+cx/IhycGA+X/7KyNBB47W+R1XNEO2272TvK5+ y50Ts31Bx/lI5QOpWUqzxgmavS5s4hvE5yybWq6AWxnCtDx4CYx52dM2iwXUmRuJCuHu 3UG45tJ9Lfr5A1U5mWUqB+7jNr8Ona6A7GbGaAzYvOM+YT1e2t2wSqktG0feG794mhze oGuTjv+KgZRZAy34/Flt8J/i5DKhNASt6NpCdZLBF3vOq0hNhSMe/b1MwY7fi6TkSOZS Yvtm1tbE5Ev0Awwyxx6GjodplU6RqOWiAgwjohY0LuKaDgTNQp8KGvqtGspTMfHBQi3i eFyA== X-Gm-Message-State: AC+VfDyX4jD3sXWfsFngnzVw3yOauXf4ljK/ZXkT6Y5pXZ0rfu2HRIFq PsXa775KgP3AQ67Po5smuyrMxw== X-Google-Smtp-Source: ACHHUZ6OXMzPI6lr8A/TCW2P1241xJOMGwaC4wkP2J02sDjyQ6VmkPnb/K7M0hGqOVx+3+wuseTcLw== X-Received: by 2002:a05:620a:8e10:b0:75b:23a1:3663 with SMTP id re16-20020a05620a8e1000b0075b23a13663mr2024531qkn.36.1685462120300; Tue, 30 May 2023 08:55:20 -0700 (PDT) Received: from localhost ([2620:10d:c091:400::5:8bb6]) by smtp.gmail.com with ESMTPSA id v22-20020ac873d6000000b003f6b98018casm4760092qtp.77.2023.05.30.08.55.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 May 2023 08:55:20 -0700 (PDT) Date: Tue, 30 May 2023 11:55:19 -0400 From: Johannes Weiner To: Chris Li 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: <20230530155519.GB97194@cmpxchg.org> References: <20230524065051.6328-1-cerasuolodomenico@gmail.com> <20230530041341.GB84971@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 47E1680010 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 4oumkm4nfiqd15ragpbm5bkp78735ar8 X-HE-Tag: 1685462121-428339 X-HE-Meta: U2FsdGVkX199rkiX0QyUIQswnW21S8IpvqoPEouZhIdgZWUixnCAPkzgRjyj4ABfCX1ztNM4OrC/Fh6mc0lxxr0dgtkLgrqEeLQWvrON2uMMAjmypcwZGwDPgyQg/yM5YMtUhuqA2ULEzxuULVE/ubGm1INppz9iYZS4jHFjaSqTsB4s2OwI5xnDl0qtPp7OOQJkZVTW31SJWyrhgCSM8MRnClj1inkY6RPFHWHVxTc7hAKtOBa7mNC/wmsWFCfP8qxg2BbsO3zIt0rAALTL4kCszhIc2A3lesyfutM3+cnJnfq67blvfTd9v8aryBO/YtnYTI05ICpZ6M2brC0WovG0PwXS77J4ObCtO2fFgFm9q4RBGKLB9nbZbH/9lyx6bCoUqEoycL8Ln6E5XpCYAQb0tYyPvy5Z+5J8fhibdDHcOtLIGAO2FFamhozla7vCCdoWL7TsQoKNS7YO3jXkaot9CBpEC9tIbuw6l8v81CysfSIsgFaEJcdK09psX3y2Wl+7UnvrhzB6n0/ZNxJ0UxRlqpQHYNTyY4vbfrbkRDB5GLRQJKcIfFZ+I5o6BlfE1Hkn6pWqFWju1uoSpccJSXfjdHVnfr9XJkU4M4ryRS6pDu1E1oQ6cQPlAKKhfaY1U1yPFOkUudxdzEfwGQdA4cU4e8yp2dQBD3h8+ZhyyXgU1lr36oRbR2v+/0m5ur42cCH9QnYp+3LTNT8CPLrKieRa612KKSQl71ALSnDJsr24m5WBIw0mhDbqxNX683PKLQaQDs0MhzIchFnQUQrvnEVDg4uK90m1gs+Lek08yBWACwUrYbJkhidYpdeyX4cDvcZSSPdm7w8m1aghVVdo5Sq16//lYzbomLrKZk8qomLEuCn1F5MxrvdwcxvCPQZPjiwgyp1d3MxGHiyX+iRGIQBMrTjAIIx8ItUxYpXCSm45kbdADDUo0Nf4AJKGoECA478Flny7eKsSdG0rNMt v5b5oqXm Vv8FwtyvOMd6nDdhuPkN+QzwwISDo9eXzKoQlcrVyr7eKclZ3Te9axMBqBLBjT4WlUCZgLE8rZELfwoWGGBl2t96vuekdvvw3+pllRwhmBN2PhjKnX0Ew5icBLQVUmEUHuF26FHJr8EyTCPW8QcJUXqaWgXgrnZNWHJYl8nENXfirLMh8xoDfTN6jLeiXX3dXSLIuqGpbdXtxZPqKjDDZgfqi1nudcR8untNYBMY+CZYXmfIYv9LL5LFWYBG9R0O4ye6WeJHmTgW0r3GUkox5xBjggAvEFMobnmpXqBdgf532c/PYP9kMWNo7TJKmY4j4nk3gYXfNavfEHF17SnRueFGHPI3WH6MEgdEV7aesB6OzFN3UOdkqdPslZWK/tKOoB31+LdVRV1XdMVKp3oudSqnKFt+t0fC+Mc44M046qoNTabc= 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 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? 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. > > 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? > > > > 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. > > 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.