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 2ED4CC5473F for ; Tue, 27 Aug 2024 23:19:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B2FDF6B0085; Tue, 27 Aug 2024 19:19:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AE08D6B0088; Tue, 27 Aug 2024 19:19:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 95A066B0089; Tue, 27 Aug 2024 19:19:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7537B6B0085 for ; Tue, 27 Aug 2024 19:19:13 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 2B0E5161A38 for ; Tue, 27 Aug 2024 23:19:13 +0000 (UTC) X-FDA: 82499593386.04.E533109 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf04.hostedemail.com (Postfix) with ESMTP id 37F9C4000E for ; Tue, 27 Aug 2024 23:19:11 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="fXJ/RexZ"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724800731; a=rsa-sha256; cv=none; b=lb+mBffsxn+Go7LedPl7Zf1+9ClGJHjvTwN0lIrq+/TyVYOr0gZNHwv6B4Xo5r9W34sHHY P1AVMEVrz1p/SBu/NlS5EjwDYsgSDHpNLFm2YSp6eSHQRm2kH/EzmF5FsWOCFXbAe6Yw5z /eQg+gYj0iuDWdIoI4ouMtpKqwKRRow= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="fXJ/RexZ"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.214.170 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724800731; 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=GUm5gryKKWvBH31Cta/VW4vv8cdFz/H0mtfUOE4BomA=; b=0olnAyP/lL39W1VG+o8ZQQrMZoOYGB9nblrtjyI6azAWBuSNucfDAfCKO8rgbxmcDj5AA5 ysIv335zxp3GQL0nuQreXeH64C00plNKDekfZLjVVn9ezDc4Hltu7bVb06sA+sMIZDn+fi RH5HwOhkb4dZTiwEsO3P5uUr0ysHq9M= Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-2020e83eca1so58260775ad.2 for ; Tue, 27 Aug 2024 16:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724800750; x=1725405550; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=GUm5gryKKWvBH31Cta/VW4vv8cdFz/H0mtfUOE4BomA=; b=fXJ/RexZRo4dzIEU/ZR+3ZmKKKMh3IhVzX5KKb1cQZ+6xw30sYojDrsfZ2SVbiJwpn kYNsAD1FTeKCc8INCbtWB8BwMZEzRXV4KmzQTA5SRSohuWLjoxpERFd2WEN1EN/pIM2Z HMrGurTxW1mZo6prGONh3k7eUHWzolzlIRAtuPqaoHiMVy2mThkjVkyEuDsjKiRfWeet L5PGSAduRFyEgcEZmeAmvQlgOZ0W2T7sLUsmUNVbQn7rFE55NBunOl+0fudLm3n5BoSF TJA0WvsH3CrYlaRwgW8MPwObUX+Fo115K3365gBVyDoq1D+gwhj0vZdw1ILgBnVFhdw4 /sdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724800750; x=1725405550; h=in-reply-to:content-disposition:mime-version:references:subject:cc :to:from:date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GUm5gryKKWvBH31Cta/VW4vv8cdFz/H0mtfUOE4BomA=; b=iQnvU/JiRHCGXr356cLIoaAYSYuuRCK/OPZyedGo2D1SlY6UOggcHJ+hs2/0y+UGuR 8bACCiBxrzPhdDHcv8d9Mc7JYUFeVLGEbgii5KOAiUM0p8yLUb5fMQyvGL1YS9g53y02 QsOMOaP2wMKmuAJiM920tzwnx+0yk0HPXBtqd3Bf3cKYIygh1MmEFm0z/DfcDx5JMJ+W YX9SAY3+6cfR0VfsUkSETCXBD87ABL2hwNgtpTE3zjHex1oJiLnNVbRqUJMC5Osx0mQU Yks6Bcw/jUD8itNB5TG8JB8ODiHBtiXVizkqgqecC5LjZmcscuMedri3zM0JJWWVFgls C5hw== X-Forwarded-Encrypted: i=1; AJvYcCXBLOns11Hk6xDryxTXq8xIyMQIEC/D9mdztWpj1W6M7eLUigmYFd0G3l6lHnexBN0fDDWmjsm55A==@kvack.org X-Gm-Message-State: AOJu0Yy7a77FK1Iw9fzWlZ7kdYD6W67I7ze/9hj+GoMYNnqSqOHVgVip rsbStgRUlPqB/tX0Kkb7+iu7sS80nB0p/GsS9Q6GT/qFlABIkepl X-Google-Smtp-Source: AGHT+IEf+YEAJ3dqp0JamhIxJ8PBWRNIOHv6jz40alBiwcH0BRAtWcl5IrKjA3M7Abz7d20cC5rlLg== X-Received: by 2002:a17:902:f68a:b0:201:efe7:cb03 with SMTP id d9443c01a7336-2039e4e84b4mr162824265ad.48.1724800749768; Tue, 27 Aug 2024 16:19:09 -0700 (PDT) Received: from DESKTOP-DUKSS9G. (c-76-133-131-165.hsd1.ca.comcast.net. [76.133.131.165]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2038560a05dsm87488595ad.214.2024.08.27.16.19.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Aug 2024 16:19:09 -0700 (PDT) Message-ID: <66ce5eed.170a0220.387c4d.276d@mx.google.com> X-Google-Original-Message-ID: Date: Tue, 27 Aug 2024 16:19:06 -0700 From: Vishal Moola To: Sergey Senozhatsky Cc: Matthew Wilcox , Yosry Ahmed , Andrew Morton , alexs@kernel.org, Vitaly Wool , Miaohe Lin , linux-kernel@vger.kernel.org, linux-mm@kvack.org, minchan@kernel.org, david@redhat.com, 42.hyeyoo@gmail.com, nphamcs@gmail.com Subject: Re: [PATCH v5 00/21] mm/zsmalloc: add zpdesc memory descriptor for zswap.zpool References: <20240806022143.3924396-1-alexs@kernel.org> <20240806022311.3924442-1-alexs@kernel.org> <20240806123213.2a747a8321bdf452b3307fa9@linux-foundation.org> <20240807051754.GA428000@google.com> <20240814060354.GC8686@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240814060354.GC8686@google.com> X-Rspam-User: X-Rspamd-Queue-Id: 37F9C4000E X-Rspamd-Server: rspam01 X-Stat-Signature: tssndo8n7ud7b4egkziyzru5zzsbpgfj X-HE-Tag: 1724800751-669511 X-HE-Meta: U2FsdGVkX19WgtF13T5pRZqTxfNmEjsA8/spna/qnXvktTLwf+arimN/9+MmEvRGzm2tWgHbllETHdmp42oajT8Q2IuwW11Jc7gaxd4X+yAOEWAmWa95MkcXACQpojSyYRjvWN4PDoVSvzFfOiFxjy/vHyYx3voJfrDiDJoBzGc0UhEt0WkjH/HTJYu2K4/SNJuDuJ4tW0cS5Zu8zBfRaVAXi1juGr3x4JZENY7x1gIMPq3zWxCkhMvHnf3Xtk5cHC+7FcAXWpU4vhOtElQQAdbXr8ldpd0ocOVeUPm98zD7sThiEhYtWYckDpxQoMqRE4dKYBGBZZurQuw0p1udRqaxiixeHrk4fflK6EfDwsWQl09OS2KG+HwH6UWt8yU62zEDvPb/CYHqfmkxDz412Tlr4hKcf2u6k+TWMRIr+a5Og1WgoijhK7p1tCxx/BgSPHhrkarRdplkxu8SNZDsfx4NNJg46AjcgGUtNxCXrPaDikh8Xi8fefk1fWOQMQ5VDmS5EL+EfyKoaNSCq43DAyCUh/2Ee17a7a2QrpEfD4aEwC4qU0oZuToJsJXqP6ON2FZfK8GEd1zC4XsGehrApLNDR3G3c52R5wK1u4x8jrH6lOV6oszZkaNTOdhN8Lsd3X3mXB9RUHF4erPNupPojbTzOugthBqwuX8pzBe/zckhe6RcIs/TRsHdwPdD9jXDJuh5Ap7y6IrmHC9gOslYqkfA5nVBazpoeurAusIoOuqzauOqKCyj8gc3mBpzbCM350Iqxonbk9o0S1Z/p90AUn/pxLXLIbhw1OVWwcW/KjwWAVPXhGiteiKozWyTQfa27LXCnaHtr2v85vOvCUdtzyFfwltltT2ueugHYjryUZRDY8y3qG4cX1wVH3jJw74gx0J4W3hspqMsmvuBunz+Agb5nxD48+83xTW5AUp0xyJxdU6JAQoCGKqZWjx7eYbiB3xRo9DHRQ8SG0V4zPz jP2gTB71 VB7nYnlStC0pEpQK7jdAQnQrud9SDL0p2BK8uTk09JJ6tgTocDwiznjaLylrOb6Ktp+K02WGqHJh8WDP1pxUryNwk9J4nSpL9U6O84mrId7BO+gITV9MZY+9AF+J/C8nru9ZoOH0SM/euHW1S9pCeAnVaRcWQcyJ4kY5gpsAwPxpR2xKS6/z3sXXhH7lP40S8JaeG6QBu4u2l+eTRyo9M7whR9VpoA+37eCQRSBLQQZbIGTRm67MvX1HKX3AMcpFaRRL0icciIsoY9jgsQc/d+3C4WOlDWDh9qHG1RTxqBh53LRz2pu1j7UMyeazfDG6QuDsxL2Az22GxVKKSXiFsOXPu8xsdkiKKAGDUU69d1NjZeBjxVSAWBV/MiYV1DNelJHodfyc3Tj0RQhLwaqeGwqMs0+Fp4MgXmzDf13a4tSbUhdt1p25/Ked3eqfMJEwmCcul24pVliP2F8V7rD7W5xMAQA== 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: List-Subscribe: List-Unsubscribe: On Wed, Aug 14, 2024 at 03:03:54PM +0900, Sergey Senozhatsky wrote: > On (24/08/08 04:37), Matthew Wilcox wrote: > [..] > > > So I guess if we have something > > > > > > struct zspage { > > > .. > > > struct zpdesc *first_desc; > > > .. > > > } > > > > > > and we "chain" zpdesc-s to form a zspage, and make each of them point to > > > a corresponding struct page (memdesc -> *page), then it'll resemble current > > > zsmalloc and should work for everyone? I also assume for zspdesc-s zsmalloc > > > will need to maintain a dedicated kmem_cache? > > > > Right, we could do that. Each memdesc has to be a multiple of 16 bytes, > > sp we'd be doing something like allocating 32 bytes for each page. > > Is there really 32 bytes of information that we want to store for > > each page? Or could we store all of the information in (a somewhat > > larger) zspage? Assuming we allocate 3 pages per zspage, if we allocate > > an extra 64 bytes in the zspage, we've saved 32 bytes per zspage. > > I certainly like (and appreciate) the approach that saves us > some bytes here and there. zsmalloc page can consist of 1 to > up to CONFIG_ZSMALLOC_CHAIN_SIZE (max 16) physical pages. I'm > trying to understand (in pseudo-C code) what does a "somewhat larger > zspage" mean. A fixed size array (given that we know the max number > of physical pages) per-zspage? I haven't had the opportunity to respond until now as I was on vacation. With the current approach in a memdesc world, we would do the following: 1) kmem_cache_alloc() every single Zpdesc 2) Allocate a memdesc/page that points to its own Zpdesc 3) Access/Track Zpdescs directly 4) Use those Zpdescs to build a Zspage An alternative approach would move more metadata storage from a Zpdesc into a Zspage instead. That extreme would leave us with: 1) kmem_cache_alloc() once for a Zspage 2) Allocate a memdesc/page that points to the Zspage 3) Use the Zspage to access/track its own subpages (through some magic we would have to figure out) 4) Zpdescs are just Zspages (since all the information would be in a Zspage) IMO, we should introduce zpdescs first, then start to shift metadata from "struct zpdesc" into "struct zspage" until we no longer need "struct zpdesc". My big concern is whether or not this patchset works towards those goals. Will it make consolidating the metadata easier? And are these goals feasible (while maintaining the wins of zsmalloc)? Or should we aim to leave zsmalloc as it is currently implemented?