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 9D520C433FE for ; Tue, 22 Nov 2022 17:43:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 24BCD6B0071; Tue, 22 Nov 2022 12:43:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F9EE6B0073; Tue, 22 Nov 2022 12:43:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C2996B0074; Tue, 22 Nov 2022 12:43:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id F125F6B0071 for ; Tue, 22 Nov 2022 12:43:00 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id AC1FF14118A for ; Tue, 22 Nov 2022 17:43:00 +0000 (UTC) X-FDA: 80161798920.03.77B80E3 Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) by imf10.hostedemail.com (Postfix) with ESMTP id EF3A1C000F for ; Tue, 22 Nov 2022 17:42:59 +0000 (UTC) Received: by mail-qk1-f175.google.com with SMTP id d7so10781963qkk.3 for ; Tue, 22 Nov 2022 09:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; 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=iA1K0/PLRcTpu9Um4AiiDo04fVuw2D9+eEQ49osbP6o=; b=vc8r77vyiXRvXUe3+AMRnVLgLCIsC4OsOCDWe3rCJW2IVov4V4YZPGLmd48QdrXls1 +lNRSeViZJLZClfY7dfx6ak8ATT5c8nlzBkZJNsBryGK2xvTCa2gqYjA3BbAcdvhm3R5 iAuDWUKnYS5KpJeBvSFZ1nKl8dYRGDCophtaB9dbUX3o89mSzuXJPCDrAwdc53E8jBtl 8IvsomWz2tBsh6QLtkrhz9eXat/HJSGMkuwuPIkW4yNYrlclY79TqbsXEh2TKU5Fc3wV wQ9g5on0TVTynx4RuL588OgF7ESmBstmn8LlE13TK0iRXM7ApqZ7958SLvbivW2B1ifO gJnw== 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=iA1K0/PLRcTpu9Um4AiiDo04fVuw2D9+eEQ49osbP6o=; b=tZFyqew/ZAymt7ByIL4YcGnAGDjWesD6IOOKg8Z8UYPoXQyRQX66S7f+tqakGv453O GUBnX+ufLHp14U8YgdwV/+Hkj/u6FW7FDZO/7eFCcdIX+yGWpVTc06HGYVI/4Af9MUW5 slb6kvRgQUgHNKj7zHcNOVoJy0O71H91P1UclWiWvzVhlUcY7h/lNtaKpC3xDfCo6/mp EiAg7D3ZJTzocPFxej+7bX+HuZN5NrUqSeJe608IjTqLrTtb8T4KTIbgIDmhRTAm3DiH 8JVfWUZ75cYeWodVqOO7EkLtOdnhKrELjbW2YEAlE+dFHQJzq/eois/qRoDsjNqwd4qO 8PPQ== X-Gm-Message-State: ANoB5pn8v1WUKfIaaUnUsMT7MHcqNZFadVew0jGas1F9UDIiYCq8qDbu 3riCK4VJSmSx2i4Qhh8XhzQk1A== X-Google-Smtp-Source: AA0mqf4963YDFZa7gZBl28D+fFDc0NIsi2mlp4Nkg2Zwd7mQGPC9mZ/14k+YxaRjg7YMrx8hwMCsDg== X-Received: by 2002:a37:a53:0:b0:6e2:285e:92ea with SMTP id 80-20020a370a53000000b006e2285e92eamr7904620qkk.213.1669138978997; Tue, 22 Nov 2022 09:42:58 -0800 (PST) Received: from localhost (2603-7000-0c01-2716-9175-2920-760a-79fa.res6.spectrum.com. [2603:7000:c01:2716:9175:2920:760a:79fa]) by smtp.gmail.com with ESMTPSA id q25-20020a05620a2a5900b006ee7923c187sm10660795qkp.42.2022.11.22.09.42.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Nov 2022 09:42:58 -0800 (PST) Date: Tue, 22 Nov 2022 12:42:57 -0500 From: Johannes Weiner To: Sergey Senozhatsky Cc: 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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669138980; a=rsa-sha256; cv=none; b=30nMrkAnPXOhxR6K2LK8I61Pw2+2zC4pf93iDYtt4JzfDNDSIH5DwJwcED6sqvhGxBWLZM CvjlrCQghqcHbfTJ+hT1DxQg0VVtqwX3PWQju1VeAz+JtAJmmxGqCvdYCeTjzRlC/nOUCI 4NUE7QiQxWEt6V1YaoNU6lKsZEBX9qE= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=vc8r77vy; spf=pass (imf10.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.175 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669138980; 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=iA1K0/PLRcTpu9Um4AiiDo04fVuw2D9+eEQ49osbP6o=; b=YIq/vZK2GrD+2ncvvaaBY5/yakeRNXJNk5nzanyvGGuZiGN1PNto8mCouRi86i/Ln4npwE rfhCRR4nCQqzvDBUZlvnTEHTQ1gAlBRYRj4INqBPQ0PxMqbD8r4HsKELZjdjtavU/t6z0q v6fQZONsYYrNU42Ln0A6R8EkOGEWiXs= X-Stat-Signature: nugm3ryoj6wcpx3geh33dr71ny958exx X-Rspamd-Queue-Id: EF3A1C000F X-Rspam-User: Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=vc8r77vy; spf=pass (imf10.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.175 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org X-Rspamd-Server: rspam02 X-HE-Tag: 1669138979-117375 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, Nov 22, 2022 at 10:52:58AM +0900, Sergey Senozhatsky wrote: > On (22/11/18 16:15), Nhat Pham wrote: > [..] > > @@ -1249,6 +1267,15 @@ void *zs_map_object(struct zs_pool *pool, unsigned long handle, > > obj_to_location(obj, &page, &obj_idx); > > zspage = get_zspage(page); > > > > +#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 > > Do we consider pages that were mapped for MM_RO/MM_RW as cold? > I wonder why, we use them, so technically they are not exactly > "least recently used". This is a swap LRU. Per definition there are no ongoing accesses to the memory while the page is swapped out that would make it "hot". A new entry is hot, then ages to the tail until it gets either written back or swaps back in. Because of that, the zswap backends have traditionally had the lru-add in the allocation function (zs_malloc, zbud_alloc, z3fold_alloc). Minchan insisted we move it here for zsmalloc, since 'update lru on data access' is more generic. Unfortunately, one of the data accesses is when we write the swap entry to disk - during reclaim when the page is isolated from the LRU! Obviously we MUST NOT put it back on the LRU mid-reclaim. So now we have very generic LRU code, and exactly one usecase that needs exceptions from the generic behavior. The code is raising questions, not surprisingly. We can add a lengthy comment to it - a variant of the above text? My vote would still be to just move it back to zs_malloc, where it makes sense, is easier to explain, and matches the other backends.