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 0CD2DC433FE for ; Wed, 23 Nov 2022 03:58:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 550966B0071; Tue, 22 Nov 2022 22:58:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D9536B0073; Tue, 22 Nov 2022 22:58:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 352ED8E0001; Tue, 22 Nov 2022 22:58:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 227B16B0071 for ; Tue, 22 Nov 2022 22:58:36 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E137C1404E3 for ; Wed, 23 Nov 2022 03:58:35 +0000 (UTC) X-FDA: 80163350190.08.EA4DB16 Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) by imf09.hostedemail.com (Postfix) with ESMTP id 7F6A3140009 for ; Wed, 23 Nov 2022 03:58:35 +0000 (UTC) Received: by mail-pf1-f169.google.com with SMTP id v28so16213744pfi.12 for ; Tue, 22 Nov 2022 19:58:35 -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=aqMP70LRlh5Jd8wsQoL6S/btce+HcGngTAhh45D7tCY=; b=BG8Nbnc69eedIhFmOpmB/urVgGyPR4LlJ79aCi0+c6F+XkXLkPkT44JnA++Nb4uF6N nLIBpCY2XsGfdprNauRVPS+iNnV7nu3ZVT5QoS41vPWIyveZpfPcrnWz6t31q3uDRje2 hGg7dBODU67l7TWxUSwHzWMELoanYoXoIQSw4= 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=aqMP70LRlh5Jd8wsQoL6S/btce+HcGngTAhh45D7tCY=; b=P3b/KpevfUnt36vIboIAeyD/YOrgfU+teQBoeZv/AFBN64h2ZvZk3oYhpwCRZNU2gJ HSiPtn9jOIECLXOqRRftpQosNjOpW9DxeOP9dqlnh7TpFekJtIq/BulBAY4jn6+TTmLa zhoguKKh+LzalSVEVDJcHLn5cnX+lERcGHjyxpaLj3GXz3wxVsrj38Jg61ot+Etuaclz OBAfqqVzjevMLzw8iY8alhNTOwlshmYwxCNBaawBI/I+2bHMQ8/lBZ9AfaD4Mpwbvg3x zxjqwuEOOQe22sq84Qx3WHxQWZeVl2hA0WmSUxmAAKtkkbzLpsGcsyC6aHGN3nAVyc25 yNoQ== X-Gm-Message-State: ANoB5pm94ymyAS8zp65NvSEjzjAzU5gOMtDlEtoAB7585/u+ym8+XXlU 1T3JuYb/QvIWDm1joHklW20XRg== X-Google-Smtp-Source: AA0mqf6nj4CwJyIsIAHJm3jBJNlvWYbYgKXDWoWItzDNm2EnpFNscAkY8r3qprwjPuBYonKnLiIDrg== X-Received: by 2002:a65:60c7:0:b0:476:aad3:90e2 with SMTP id r7-20020a6560c7000000b00476aad390e2mr6038117pgv.217.1669175914415; Tue, 22 Nov 2022 19:58:34 -0800 (PST) Received: from google.com ([240f:75:7537:3187:b570:e8d2:6522:6054]) by smtp.gmail.com with ESMTPSA id t21-20020a17090ae51500b0021894e92f82sm330530pjy.36.2022.11.22.19.58.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Nov 2022 19:58:33 -0800 (PST) Date: Wed, 23 Nov 2022 12:58:28 +0900 From: Sergey Senozhatsky To: Nhat Pham Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, minchan@kernel.org, ngupta@vflare.org, senozhatsky@chromium.org, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com Subject: Re: [PATCH v6 4/6] zsmalloc: Add a LRU to zs_pool to keep track of zspages in LRU order Message-ID: References: <20221119001536.2086599-1-nphamcs@gmail.com> <20221119001536.2086599-5-nphamcs@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221119001536.2086599-5-nphamcs@gmail.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669175915; a=rsa-sha256; cv=none; b=p/aDg2/QNyw0dehC8IYQHWtjdlSXPmHsFZpNjSqjAidE8KHFMFapkgNGCvlxQaMTQGmEmV or0EeZ4+DzwMLX2fju0MyzlNxgEYq1fELxFBwLmxwnJnIFwT6KbYYOOBX6tygkiHmjYRvU E3AxPeIsvuOhY2ESEme9Kt2B75HatBo= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=BG8Nbnc6; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf09.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.169 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669175915; 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=aqMP70LRlh5Jd8wsQoL6S/btce+HcGngTAhh45D7tCY=; b=icsRniDzYGoPzxLiFLFczHx3Msj7UGEMbUJshVEsOKw0uukUFW5pPW2JtOF520d1Rlc8DS FKZkIws8YXt1ytqzjKTca7mAjjgyE9ULe/wywhxSlWOwiLm+2xptejxb878nlVNcbPpfhS ytTrO5qSQavrish/pln7q4H0MckXR3M= X-Stat-Signature: y84mq8fxnc5tujzocpcj4r8b41c49ewy X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 7F6A3140009 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=BG8Nbnc6; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf09.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.169 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org X-Rspam-User: X-HE-Tag: 1669175915-98858 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 (22/11/18 16:15), Nhat Pham wrote: > +#ifdef CONFIG_ZPOOL > + /* Move the zspage to front of pool's LRU */ > + if (mm == ZS_MM_WO) { > + if (!list_empty(&zspage->lru)) > + list_del(&zspage->lru); > + list_add(&zspage->lru, &pool->lru); > + } > +#endif Just an idea. Have you considered having size class LRU instead of pool LRU? Evicting pages from different classes can have different impact on the system, in theory. For instance, ZS_FULL zspage in class size 3264 (bytes) holds 5 compressed objects per-zspage, which are 5 compressed swapped out pages. While zspage in a class size 176 (bytes) holds 93 compressed objects (swapped pages). Both zspages consist of 4 non-contiguous 0-order physical pages, so when we free zspage from these classes we release 4 physical pages. However, in terms of major page faults evicting a page from size class 3264 looks better than from a size class 176: 5 major page faults vs 93 major page faults. Does this make sense?