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 B2A1EC433FE for ; Tue, 29 Nov 2022 15:54:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 02FCD6B0072; Tue, 29 Nov 2022 10:54:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F22936B0073; Tue, 29 Nov 2022 10:54:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DC2E86B0074; Tue, 29 Nov 2022 10:54:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C83756B0072 for ; Tue, 29 Nov 2022 10:54:24 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8BB8E4091C for ; Tue, 29 Nov 2022 15:54:24 +0000 (UTC) X-FDA: 80186926848.30.B966038 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by imf20.hostedemail.com (Postfix) with ESMTP id EF11E1C0003 for ; Tue, 29 Nov 2022 15:54:23 +0000 (UTC) Received: by mail-qt1-f171.google.com with SMTP id jr1so1035977qtb.7 for ; Tue, 29 Nov 2022 07:54:23 -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=3MZ0P22eZbT2LoWXuBc+NaiT5UofF++vBgLaQchK06k=; b=vBLgT7GncsxnI7YHNF1M/hBCGJ1BDruwVuoRpqwL3j1bsDrfOowrud81uwfvsAhSBg jBG8DniuxCEaX344IhAHSD85tpqiZZqckP3L32jk9iMtv3gl7eN69ai7GGK12xg4fYIv A3z8UKYKOCxX4IIrqKfEiVIMcN5KkQ9lSXVClS/nSuTFqkaR5cHIuF+MEB+NjiG+TLLJ P1U/mFtT6S/CwQJcIScou3DKvpuhIpdbGIeOW/KBYfwoXU32kQvvKl6mk+3t17Eb9VPt jgJ/dZhYJB+qbKPFXWRhAOn0XGa682SGcb4C6suA3YWO72buB8snn0SJmLcfx0r5e11b S6OQ== 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=3MZ0P22eZbT2LoWXuBc+NaiT5UofF++vBgLaQchK06k=; b=iO6/ge+UIKcVa1CembdwjonxIbUMVGe9qNS0cspvhTH+e5yoojsirpkIC9lqaDLqVB lOkSOK9AjIvY4yVrFW81CYiK81N/Bbm8YDQLOomr7BlP2Fbts8HGweMOdi+bSTegnMIA 8UBgBOzoSrC0mIvX+kWbVqJbiSBkYIQQWwvZQ+vS8rBFseUTdmsaintbF6N30KczmU7Y zASsvAvkacPv2a+mnzHTKoZUlqq5VkgCcARkabqiPurFhpzprK/+hs4H0KK7mLKrltIV aQAt20TqiXIqj+TwrBZpRnY7JmV0z8zuVD+rLrhiBFiug8gEg4A+rmMRGlxM597QtCKE GgNg== X-Gm-Message-State: ANoB5pk3zGQYAmNFvOKZ0ljPY3x3y4/zauLJXg0RbG1c+MW/6/t8vAgC ST1cR/t4xkoVe8T0DtBqCWWNqg== X-Google-Smtp-Source: AA0mqf4oKvSWCujdTl6t2i3G/hJjIRdSrYNV1/0SajLPgSolL4WWDryzk2+X/8x+lMlh7B24AG21uA== X-Received: by 2002:ac8:1347:0:b0:39c:b637:a890 with SMTP id f7-20020ac81347000000b0039cb637a890mr52739459qtj.613.1669737263151; Tue, 29 Nov 2022 07:54:23 -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 g11-20020a05620a108b00b006ec62032d3dsm10533307qkk.30.2022.11.29.07.54.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Nov 2022 07:54:22 -0800 (PST) Date: Tue, 29 Nov 2022 10:54:21 -0500 From: Johannes Weiner To: Sergey Senozhatsky Cc: Vitaly Wool , 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 Subject: Re: [PATCH v7 4/6] zsmalloc: Add a LRU to zs_pool to keep track of zspages in LRU order Message-ID: References: <20221128191616.1261026-1-nphamcs@gmail.com> <20221128191616.1261026-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=1669737264; a=rsa-sha256; cv=none; b=WkEJE/7oh1LO1M6e0FvceO2YRWVmS9CdXKGybbooe9kIJF9BAPGKsEhdzyibsv8L0OBeMZ m8Z6tY7QVekhS0OIk2B25LVG7TbAIUMq+ULsBRx65gHrCZeXS1lAh0i/EHBOe/oTRR0YUd GiILYZHIBXQHMjg6XXf/tzUIl1Bw9h4= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=vBLgT7Gn; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf20.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.171 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=1669737264; 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=3MZ0P22eZbT2LoWXuBc+NaiT5UofF++vBgLaQchK06k=; b=c7S1WURbA9dSkm0VcVPGfe0lSTq991jr1SZHqOSHoig3Qz2xSs4t8k27gSRT1jvnPegW5i 7FXTci7ecAe5vSypjiddYj7g5f4FW+OHLI/hm7Ve6y+RcY1tHGHn/yKvEWw/oWYeLHoLMc oX60PHbOobDpgCQDTwjdL743tp9oMx8= X-Rspamd-Queue-Id: EF11E1C0003 X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=vBLgT7Gn; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf20.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.171 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org X-Rspamd-Server: rspam09 X-Stat-Signature: e7gos1ccsorhcwupw79fxfedzsy6mi5h X-HE-Tag: 1669737263-212550 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 29, 2022 at 11:03:45PM +0900, Sergey Senozhatsky wrote: > On (22/11/29 12:53), Vitaly Wool wrote: > > I think the amount of #ifdefs here becomes absolutely overwhelming. > > Not that zsmalloc code was very readable before, but now it is > > starting to look like a plain disaster. > > Presumably most of them will go away once LRU moved from > allocator to upper level. Yes consider it the "cut here" lines for refactoring the LRU into zswap, which we want to do next. They're not here to stay, and that work will remove a lot of duplication and complexity from all backends. So I hope it's acceptable as a transitionary state.