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 7BC10C77B7A for ; Fri, 26 May 2023 18:10:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 93F01900003; Fri, 26 May 2023 14:10:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8EF1E900002; Fri, 26 May 2023 14:10:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7B74C900003; Fri, 26 May 2023 14:10:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6C4FC900002 for ; Fri, 26 May 2023 14:10:28 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2B0C0401E6 for ; Fri, 26 May 2023 18:10:28 +0000 (UTC) X-FDA: 80833196136.28.2F763CB Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) by imf07.hostedemail.com (Postfix) with ESMTP id 25D8740010 for ; Fri, 26 May 2023 18:10:25 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=cmpxchg-org.20221208.gappssmtp.com header.s=20221208 header.b=reDng+rZ; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf07.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.47 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=1685124626; 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=37tg7T594fYkzDsLRmJ/Q/EtJuUqNxmb+GPO0Hq9YXs=; b=jFJ8d71PtMOKb70l81XnEor34770/icbnWc/mXEYJcsOqShxBVuUr+wBdIL5GfHrArbj/o o0i4LDOlKZvA+p74Z5ti+I26merTc0CbNa4KANdayI6sqafjbHVcz2eJTuly4g3/YZl12B hBeQn30PGf94q4vGXPNMQJg73AbeT2I= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=cmpxchg-org.20221208.gappssmtp.com header.s=20221208 header.b=reDng+rZ; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf07.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.47 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685124626; a=rsa-sha256; cv=none; b=TuDSz1q3w7LKzXMVwjNz1hLLOyL+haJuX+LT3R7iooqJd3vYN3x+2BazFnZdnrvqhNB9ks diVZ0oVMVPnAp5mYcRQ7NCxdiGyyRcBWtVZiQljpxTY9FDMrAd8wck4feZQ7N1TOlVq/8j RENZtFwgsgi0QcX4jZQLjCpLTKJVmBU= Received: by mail-qv1-f47.google.com with SMTP id 6a1803df08f44-6239ab2b8e0so12440936d6.0 for ; Fri, 26 May 2023 11:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20221208.gappssmtp.com; s=20221208; t=1685124625; x=1687716625; 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=37tg7T594fYkzDsLRmJ/Q/EtJuUqNxmb+GPO0Hq9YXs=; b=reDng+rZ41X+8kbVvk70QgEyAxMMtYhYluWthz2mr1dSMs9TYcu11xcUgRJVfXN/Sm jY2o62DOBoN88bBnQIE9rS9eSnRe5uBwY5reg87S0Fw8eF935S0hxcsnfE71Y2SfhuNE ouBIF281iuZI8dNIwTaZSuS2dCjDNsrCnQXulfe+I2wwCM3cjnnHIW9jI3oyIfOx4J31 VNv5J4sXrExqpCPJEcJ60teSfibqRBVG8GM65lDtPTMncU5dCKEKP6G6Tl20n4mLq/5a gs835RbxW30qIs5A+9Qo5H8xsTkWrDMfI6hhLylFh4Vq0DMeXLRGsBWsMlx56KTFAbRT BkLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685124625; x=1687716625; 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=37tg7T594fYkzDsLRmJ/Q/EtJuUqNxmb+GPO0Hq9YXs=; b=ANw9j2jAh+1Ztjhqs/6m0Qas45OweQm3jppadjFO94zsupyajGUhJfo4PlffnSvsyw wuFGD/N8XaBe4El84wYOnXvb1MyN3h9mtFzC+1fMSbRw1PJxyVqBJZF95T1qMje46dt3 3KbtE9ZCNDavdW+Pt/slnjbobqMZ3nr0QujWISAPkO2tg8IorHog8+YaMrvu+p7rT+d+ agM0/SO6GqdO8HrU/pnnn1yokIu8D58GwMHEBFYIhJBF02J3yVhBGuJywCh3Mm0UFXIi 3ZmJX8Q/a5O+sKE3yhd1dkxmygThOP9hXZksgcKdgE7q4SNWv8ZNoCupccctLZNZXQzN UdRw== X-Gm-Message-State: AC+VfDzsuol2p9HY/rods1EZS1Y9Dxc/fhWa5z+y61G7u+rjoL1jBwDJ 9ernu/W1Pk0pnAse9zVnPhc0ug== X-Google-Smtp-Source: ACHHUZ6oawaOs+6t1Ee0cteRC9QmCsKo/5UJS1rWK9TQ6iGOtaGL//yRiVETzvyhQ+kUGwyk5HaOjQ== X-Received: by 2002:a05:6214:29ec:b0:625:8b9a:b426 with SMTP id jv12-20020a05621429ec00b006258b9ab426mr2902811qvb.46.1685124625036; Fri, 26 May 2023 11:10:25 -0700 (PDT) Received: from localhost ([2620:10d:c091:400::5:8bb6]) by smtp.gmail.com with ESMTPSA id g14-20020ae9e10e000000b0075cb3e8ad1fsm764918qkm.83.2023.05.26.11.10.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 May 2023 11:10:24 -0700 (PDT) Date: Fri, 26 May 2023 14:10:23 -0400 From: Johannes Weiner To: Domenico Cerasuolo Cc: 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 v2] mm: zswap: shrink until can accept Message-ID: <20230526181023.GA49039@cmpxchg.org> References: <20230526173955.781115-1-cerasuolodomenico@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230526173955.781115-1-cerasuolodomenico@gmail.com> X-Rspamd-Queue-Id: 25D8740010 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 6az5h15dktqpqfxt3zy1awudke848y3w X-HE-Tag: 1685124625-792195 X-HE-Meta: U2FsdGVkX1+TdxUOqbv06MJibX3+TW1OIxJ9nXbLTz8F2Ao5sFp5f02XIJO09XctyiCijGofWVjO6JcGrYBucgDDfHR/pRLEYgw3u+NN7zFBpt9d/vBs2Bn+zZaaofTXzQ29Z9Jgm+/DDz++bBmr5RrFzlqM+hpm5soR8qmpcITFEJGF7d/Hsg2+3lqKvzmxWoObecjTuV/9kId1QL1ZAiJuIZxEGIZPy+XwQ5ZZ6Vvfnt65QCbN7elwDxOp5g5XEDg9HkT5SNwA1lVOIxcBL0MANOfGXYaxoY+a9hR7+Jce1VeKzriAyr/cQN4fypyxejLTnxCvduzi8p8b1IH3csLZn+ZXnHNOcgvLR6gUxVzrd1ZHBSL2kHq3dUOX94GskYjgFcyj4FGMi38s2HjoY7CTIbGP2csdizz7QaSVTrknwpOcnAA2WSeqvilMlhb+7lCt9cXSLmoWM+s0xj1L8xhCOt3U5/mK55J1BZ4thTHyqyryKSmaxZLVq1an/QwRupY+oM8q80YK6ZBdpDyDiWi99+NCqgG+AV8YZ960cqJ24Cb4qQzgIL4ZtLawmaZVMIun63dDb5jLGICqtEl/Xx9gTtXXfOk9Jo0/PYN+xNKh4RkieWK2j/hvxjFy5LxpolUgTrC5uKAjEoSNwnFxs47p5vwp+ZGUfU9wnVDw2EkI8eRtfdulzM0GZ8oeQNZYGH32kfspUz7JIZCbNrWQWkTzFed6JO53Fko90Eg+oZ6jhKEGR0AezXUvX/9JREf9yEMeOjeDZsC8IUtYXwxu7pgMuxYTvEvp4G1LCVrRbnVjkL3yFfXLRvRHe5MjLjNAaunHVdvfPQDNU1545PYVYSaN0drI9ehDQd1hR1SNqTNPm1UmlyEDUx7HuiZXpDggAzDTgO49d2Ux6/T6qKbGGm8oyaK82/1KRAsmfUtl7EVjZsVaMyYj5RE6YxJPhNfCejwZe89IrnbS/AfZWDD sjQljTpX +Av1HH66BstPP9SvDN1yMhfaqtQYBbRtoYY+ZDnm7anQNEueHd4YweHORmA5vyqz0mPPVu6CfI6JIbuCdkmXlq+TrtRcE3ycfwjmNA0kh1Kw7NXk3tl+PpAaaC2+aA1uOHqMO//1H3IUTnady45cjBIo1ZlBDQAi8IRag0S6VVEVL0ZAWB4O7sHRZrFUhyok1LjLgiZ/wQ0LzAFeJm0S5D31L8CkesjhZUziza9p19Di5UpH+GOPqule9wIZsC54kQrakv1quey+X1ymnRoKzu9CS/QbtpSEafzU8T1t3mHW0wzl5Oj8PyEycNUog/VgWHUcj0sffPuyZe3QJnk2U0RDarPi+ZNtB/kopP8dCc+Rx2pjR7KeNYJMZOGcgPPKvVU05o4tBnQJli6P5WSRsyTmk2JPsjuJqMyK06stE7FChHSZzNA/am9np1XgE2TADrCNP X-Bogosity: Ham, tests=bogofilter, spamicity=0.000192, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, May 26, 2023 at 07:39:55PM +0200, Domenico Cerasuolo wrote: > This update addresses an issue with the zswap reclaim mechanism, which > hinders the efficient offloading of cold pages to disk, thereby > compromising the preservation of the LRU order and consequently > diminishing, if not inverting, its performance benefits. > > The functioning of the zswap shrink worker was found to be inadequate, > as shown by basic benchmark test. For the test, a kernel build was > utilized as a reference, with its memory confined to 1G via a cgroup and > a 5G swap file provided. The results are presented below, these are > averages of three runs without the use of zswap: > > real 46m26s > user 35m4s > sys 7m37s > > With zswap (zbud) enabled and max_pool_percent set to 1 (in a 32G > system), the results changed to: > > real 56m4s > user 35m13s > sys 8m43s > > written_back_pages: 18 > reject_reclaim_fail: 0 > pool_limit_hit:1478 > > Besides the evident regression, one thing to notice from this data is > the extremely low number of written_back_pages and pool_limit_hit. > > The pool_limit_hit counter, which is increased in zswap_frontswap_store > when zswap is completely full, doesn't account for a particular > scenario: once zswap hits his limit, zswap_pool_reached_full is set to > true; with this flag on, zswap_frontswap_store rejects pages if zswap is > still above the acceptance threshold. Once we include the rejections due > to zswap_pool_reached_full && !zswap_can_accept(), the number goes from > 1478 to a significant 21578266. > > Zswap is stuck in an undesirable state where it rejects pages because > it's above the acceptance threshold, yet fails to attempt memory > reclaimation. This happens because the shrink work is only queued when > zswap_frontswap_store detects that it's full and the work itself only > reclaims one page per run. > > This state results in hot pages getting written directly to disk, > while cold ones remain memory, waiting only to be invalidated. The LRU > order is completely broken and zswap ends up being just an overhead > without providing any benefits. > > This commit applies 2 changes: a) the shrink worker is set to reclaim > pages until the acceptance threshold is met and b) the task is also > enqueued when zswap is not full but still above the threshold. > > Testing this suggested update showed much better numbers: > > real 36m37s > user 35m8s > sys 9m32s > > written_back_pages: 10459423 > reject_reclaim_fail: 12896 > pool_limit_hit: 75653 > > V2: > - loop against == -EAGAIN rather than != -EINVAL and also break the loop > on MAX_RECLAIM_RETRIES (thanks Yosry) > - cond_resched() to ensure that the loop doesn't burn the cpu (thanks > Vitaly) > > Fixes: 45190f01dd40 ("mm/zswap.c: add allocation hysteresis if pool limit is hit") > Signed-off-by: Domenico Cerasuolo > --- > mm/zswap.c | 15 ++++++++++++--- > 1 file changed, 12 insertions(+), 3 deletions(-) > > diff --git a/mm/zswap.c b/mm/zswap.c > index 59da2a415fbb..f953dceaab34 100644 > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -37,6 +37,7 @@ > #include > > #include "swap.h" > +#include "internal.h" > > /********************************* > * statistics > @@ -587,9 +588,17 @@ static void shrink_worker(struct work_struct *w) > { > struct zswap_pool *pool = container_of(w, typeof(*pool), > shrink_work); > + int ret, failures = 0; > > - if (zpool_shrink(pool->zpool, 1, NULL)) > - zswap_reject_reclaim_fail++; > + do { > + ret = zpool_shrink(pool->zpool, 1, NULL); > + if (ret) { > + zswap_reject_reclaim_fail++; > + failures++; > + } > + cond_resched(); > + } while (!zswap_can_accept() && ret == -EAGAIN && > + failures < MAX_RECLAIM_RETRIES); It should also loop on !ret, right? AFAIU Yosry's suggestion was that instead of breaking only on -EINVAL, it should break on all failures but -EAGAIN. But it should still keep going if the shrink was successful and the pool cannot accept yet. Basically, something like this? do { ret = zpool_shrink(pool->zpool, 1, NULL); if (ret) { zswap_reject_reclaim_fail++; if (ret != -EAGAIN) break; if (++failures == MAX_RECLAIM_RETRIES) break; } cond_resched(); } while (!zswap_can_accept());