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 AF8F5C433FE for ; Thu, 24 Nov 2022 03:21:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BBB1F6B0071; Wed, 23 Nov 2022 22:21:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B6B2C6B0072; Wed, 23 Nov 2022 22:21:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A33166B0074; Wed, 23 Nov 2022 22:21:41 -0500 (EST) 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 957F56B0071 for ; Wed, 23 Nov 2022 22:21:41 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 555CA1403BD for ; Thu, 24 Nov 2022 03:21:41 +0000 (UTC) X-FDA: 80166886002.09.4A71AFD Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by imf04.hostedemail.com (Postfix) with ESMTP id E111440006 for ; Thu, 24 Nov 2022 03:21:40 +0000 (UTC) Received: by mail-pl1-f181.google.com with SMTP id io19so318941plb.8 for ; Wed, 23 Nov 2022 19:21:40 -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=IHv32wwTpzBjTynX/gdAaEUNtv1wZDAgeTnBSrXjjGI=; b=DEygdYza5G8MwNI5sNBZ3XingdLfN4mbDYfS396z5R8GJsj4HGQrtX4QBbJM80BNq0 aT7XL1m85vcYO1bnbIPByFyqgIVw1USABubQuEsUpJjgpqSw3DusTnvYh65McgqcjP9J Wtki4hHNXClWs8RvZ3RljGZAIsoJCY2aoIuKg= 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=IHv32wwTpzBjTynX/gdAaEUNtv1wZDAgeTnBSrXjjGI=; b=RB8SIi3WNmLlpOdePOOO9ncFQzVR/Np2GXvnvhjUwvxjjH7s9GMMSrAtWVXkVPh9J8 Q1h7yaKeC8EVh7HnKpBDZbT7XGRC8KCJvqYo/w4WsHaXAZSlq+mPWYfY/t4sFfwjXkcA aEcpd3LTCSKr9ViWA623bpxWssKbPx4djGadw2Izdh5d5cHsXZzqXws06ncQjoP12Cgr J5XDAI2i21v1DwU76EjztuMXx6gld/0NdBrzVPsp5bMcJsFelgQc6X0n23KSjkvsk+ly 3c2obK1lUJgwyIaLG6+sm38sZyy4c6ITnLHgJVJiycCWCONN7ZM1LEsDdXdkYNXWTvf5 jDfA== X-Gm-Message-State: ANoB5pn5NBMwuy8JHxqlcl97iGoQ8pQsQRhDT5oneXjxSwSim5H7EyWa ba0auM6Juashi7AVebpVz7oFcQ== X-Google-Smtp-Source: AA0mqf45doR8yCL5Lt/QjpyG5w0fUlinFLijPOIFOgHp6OfcvHjismnlLfmJTmpgbjHSUdWEng3IFg== X-Received: by 2002:a17:90a:4886:b0:211:42a9:d132 with SMTP id b6-20020a17090a488600b0021142a9d132mr34019411pjh.8.1669260099592; Wed, 23 Nov 2022 19:21:39 -0800 (PST) Received: from google.com ([240f:75:7537:3187:438d:8b02:662d:50b3]) by smtp.gmail.com with ESMTPSA id i15-20020a17090332cf00b0018544ad1e8esm15180038plr.238.2022.11.23.19.21.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Nov 2022 19:21:39 -0800 (PST) Date: Thu, 24 Nov 2022 12:21:33 +0900 From: Sergey Senozhatsky To: Yosry Ahmed Cc: Sergey Senozhatsky , Johannes Weiner , 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 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: ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=DEygdYza; spf=pass (imf04.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.181 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669260101; a=rsa-sha256; cv=none; b=6ezcXH1Dd3J4UG1JrujRMQNbVl383v3NJVpykv8viA1x9cn2+aHaCdeS58D3pb9ccGEzLc 5Had1W87UhTj8YGhXpYB6BDBXg+WqbJles80ijtnNIYPxqW0rNsgkFObbONr+QxIaAmqGV 59uDX8D9M6tlE7ZfZnOb9/sII9+DEdw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669260101; 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=IHv32wwTpzBjTynX/gdAaEUNtv1wZDAgeTnBSrXjjGI=; b=CU6DlZomYTnAigthL85nXyQfeiUGhwprK6GRKc0l9ReS+6Jt5d7kCMaqQlzK/PBQL+fOmp eqAKwUwwZR/PaBlyTuRpEcrrcRaqM2/LhVUtf6/0WVF2X7TIFDpbFrY7oSYewNfzDITfI/ dvpn5W5wYfMXNymTUGy0ce4XGs9gBvw= X-Rspamd-Queue-Id: E111440006 X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=DEygdYza; spf=pass (imf04.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.181 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Rspamd-Server: rspam06 X-Stat-Signature: 76xwqj7e73nmzh64bf4jzcaoyoeynckp X-HE-Tag: 1669260100-706651 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On (22/11/23 00:02), Yosry Ahmed wrote: > > There are no accesses to swapped out pages yes, but zspage holds multiple > > objects, which are compressed swapped out pages in this particular case. > > For example, zspage in class size 176 (bytes) can hold 93 objects per-zspage, > > that is 93 compressed swapped out pages. Consider ZS_FULL zspages which > > is at the tail of the LRU list. Suppose that we page-faulted 20 times and > > read 20 objects from that zspage, IOW zspage has been in use 20 times very > > recently, while writeback still considers it to be "not-used" and will > > evict it. > > > > So if this works for you then I'm fine. But we probably, like you suggested, > > can document a couple of things here - namely why WRITE access to zspage > > counts as "zspage is in use" but READ access to the same zspage does not > > count as "zspage is in use". > > > > I guess the key here is that we have an LRU of zspages, when we really > want an LRU of compressed objects. In some cases, we may end up > reclaiming the wrong pages. Yes, completely agree. [..] > Ideally, we would have an LRU of objects instead, but this would be > very complicated with the current form of writeback. Right. So we have two writebacks now: one in zram and on in zsmalloc. And zram writeback works with objects' access patterns, it simply tracks timestamps per entry and it doesn't know/care about zspages. Writeback targets in zram are selected by simply looking at timestamps of objects (compressed normal pages). And that is the right level for LRU, allocator is too low-level for this. I'm looking forward to seeing new LRU implementation (at a level higher than allocator) :)