Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp5459054rwb; Mon, 21 Nov 2022 23:39:03 -0800 (PST) X-Google-Smtp-Source: AA0mqf7GtHKgS1wrw/eemIproKSvWcnxrp3IwD3G23+5p1bIty7BfrZCDY6Fl/zsZ3MdkzI+JxJM X-Received: by 2002:a17:90a:2fc1:b0:218:8452:e1d2 with SMTP id n1-20020a17090a2fc100b002188452e1d2mr20473315pjm.112.1669102743272; Mon, 21 Nov 2022 23:39:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669102743; cv=none; d=google.com; s=arc-20160816; b=aVTPPgo9ex/9kQFiwbANixTgUB1MdXDJbQuovjgCcw/6Prj3IPgu7V3ziSaFqbjt99 SsAE/0DH2jB8aqe7BcAZ+Kl8+IbAkuluHwGp1mTmlkeal1PAC68f4mY6xyq2NlWgd8Aj M2jFkkdPKMztB2caGb3Xz4hlU1t3p1ojFmbchcYLGVYqNkTA/lO0sJHrAxV3ZCZDYmXL Rw+u5nQnXdHhySIDKzSj1rnHvjrj5yhtVVMPUMd4mHgONa9ROfwNIwgWeNub+5Gweu+1 swysy9/jxOL9GN9ZSIKStRDKeXAcLKHyCV2v2t9X+a+ZXNJKfxmBwuhSNMEnP7Wmck8T sOKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=zqEub+lBBfeFrlj2C/SHm/KndBPQPD1Sh86dd+BHV10=; b=JgNZmKd0t3KPsebocMQTz1yfCkYWb17C2LRgTAKRRv5KjD088siYseWTdFXXHLM7A8 Px94Kob9b9UQz52UqpR/mYtbnLhsXHkKTCesZSuLFWoyJU+Z1TK6AezQtzIFf5OGROO/ +R8CuzUXIMLFzMP8IA3lBlTbvjstCWj2wjPTyCOg/uZ3LA6l30fL6s2ym9d0KqN51eYl Hc1U2UzNMmT7eE/ugobWSWbbEMATa02nMhULpYDDbQRXQvvg5/d8T5KGmwe0At8llqER uJRrckisoJMdGqqOKgjdLjMNo9iiyRL23P87PbQ4uDCDM+RphADNA6R66i7bHdXTYAi3 7jTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ev5UBIGz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m13-20020a63fd4d000000b004404162e5e0si4781113pgj.593.2022.11.21.23.38.50; Mon, 21 Nov 2022 23:39:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ev5UBIGz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231998AbiKVHTX (ORCPT + 91 others); Tue, 22 Nov 2022 02:19:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229497AbiKVHTU (ORCPT ); Tue, 22 Nov 2022 02:19:20 -0500 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 72E1F31226 for ; Mon, 21 Nov 2022 23:19:19 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id 4so12839820pli.0 for ; Mon, 21 Nov 2022 23:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; 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=zqEub+lBBfeFrlj2C/SHm/KndBPQPD1Sh86dd+BHV10=; b=ev5UBIGz62POaB/vsQAV1UYI1ZXeprMiRqs2YCiF5YudXKHXXORVNPt2w11KQ6pJxD L3tsvm9L8akWafdgBGvk3kR6AJC1lF3vW3ogxSMPOnreZa8EJ+HLYsvKHrGiSnYPpdQU rUpp4op6r0HxCHciWDdct9k5Erxv3YeF2BKKw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=zqEub+lBBfeFrlj2C/SHm/KndBPQPD1Sh86dd+BHV10=; b=qeopa8k1BDS1SHbZB7QZs7MgsKuN9U3HN3IKC/ulMiMOoEbwd6TfCgsxBL7h7ViRkx KSsHYBsxPmpDQExSvL5UmahGYEGV4ZnZVLuWSp5KmEc36nI65bWhJ7pm20DSQJngQ9P/ ICCrNsCLPaUQqV4GODyiQ1RBcz/p6qfP0A1KrShZUiu13clk5lrv+sAAy4gDrEexVn+B q46g9oE7YkINNEE4pIBViBaHLvap8kF6FcQEj7VN8uwGorY8QSLL01JOhNWWKiomxogP lm8iNwMHsLLEVd/oSob/F6/5YRl8saG18BFo9GSqBZ4Px4HCCVIRgEEL5ot0uKkbFfIp i4Tw== X-Gm-Message-State: ANoB5pljBb5oNQzpc5i13FPLUXFtybW6oUNEzKfjg0wHtK56Iyies5vQ NzaMHQR9RbAqFU/0JynIxm2voA== X-Received: by 2002:a17:902:ce04:b0:174:af35:4b90 with SMTP id k4-20020a170902ce0400b00174af354b90mr2772552plg.8.1669101558926; Mon, 21 Nov 2022 23:19:18 -0800 (PST) Received: from google.com ([240f:75:7537:3187:e258:71ac:37b7:2d52]) by smtp.gmail.com with ESMTPSA id q15-20020a170902dacf00b00186efc56ab9sm11158142plx.221.2022.11.21.23.19.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Nov 2022 23:19:18 -0800 (PST) Date: Tue, 22 Nov 2022 16:19:13 +0900 From: Sergey Senozhatsky To: Johannes Weiner Cc: Sergey Senozhatsky , Nhat Pham , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, minchan@kernel.org, ngupta@vflare.org, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com Subject: Re: [PATCH v6 6/6] zsmalloc: Implement writeback mechanism for zsmalloc Message-ID: References: <20221119001536.2086599-1-nphamcs@gmail.com> <20221119001536.2086599-7-nphamcs@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (22/11/22 02:10), Johannes Weiner wrote: > > Yes. "What if it would continue". Would it make sense to not > > break on EAGAIN? > > > > while (total < pages) { > > ret = zs_reclaim_page(pool); > > if (ret == -EAGAIN) > > continue; > > if (ret < 0) > > break; > > total++; > > } > > > > Then we don't need retry loop in zs_reclaim_page(). > > But that's an indefinite busy-loop? That would mean that all lru pages constantly have locked objects and we can only make partial progress. > I don't see what the problem with limited retrying in > zs_reclaim_page() is. It's robust and has worked for years. No problem with it, just asking.