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 EFEBFC83013 for ; Thu, 29 Aug 2024 09:42:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ACD586B00B0; Thu, 29 Aug 2024 05:42:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A7BBD6B00B3; Thu, 29 Aug 2024 05:42:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8CE0C6B00B1; Thu, 29 Aug 2024 05:42:16 -0400 (EDT) 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 6A80C6B00A9 for ; Thu, 29 Aug 2024 05:42:16 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 185F1120D18 for ; Thu, 29 Aug 2024 09:42:16 +0000 (UTC) X-FDA: 82504792272.26.1B10CF9 Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by imf21.hostedemail.com (Postfix) with ESMTP id 22BEE1C0009 for ; Thu, 29 Aug 2024 09:42:13 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fnz74GH4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of seakeel@gmail.com designates 209.85.210.176 as permitted sender) smtp.mailfrom=seakeel@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724924468; a=rsa-sha256; cv=none; b=PKr9Ucd5LUZxocz13g13u93DA08tqlsBNuWrJmTTUdiCHSQyk1GDxv61B6RIoz/wYVRd+y 2Ur+tKytRF9CAlHrLji5z0UnELPJR8IJyL7hT7ni+iSvPwPmgDVJ3MVexUdP7cGB5LeCU6 ZjNOc8EFAsjwByr09vrh44u36Luj2Co= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fnz74GH4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of seakeel@gmail.com designates 209.85.210.176 as permitted sender) smtp.mailfrom=seakeel@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724924468; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=g5Mg16IGZHR1AU9QEpDlBdQnYhxBBYTm7k573SZhd6E=; b=H5oTU3fZneStT0gHH0UrtFg3krUmmALySjiqaIvhIvAR4YKrPqJuAJNuCEEL5aFutCathA htcyf2R1DUZlrfGdQ+Ibc//JUBGkYjoGNtWUKZseV3M3+EoDpU8HvYO3/btOYqHxtryt+w lJX6yjCT3XxRHAzC+LBM8Psav7JhO1E= Received: by mail-pf1-f176.google.com with SMTP id d2e1a72fcca58-7142e002aceso382418b3a.2 for ; Thu, 29 Aug 2024 02:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724924533; x=1725529333; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=g5Mg16IGZHR1AU9QEpDlBdQnYhxBBYTm7k573SZhd6E=; b=fnz74GH4VkqNsv0hxStxpUPwYHjkm6Wpx1yOhhPiIIJ70/oWzlPmVbe9Fh7nNuHrWb ejhbAbKIrpMhAgbkGRsAX1Bm5DAwYJnC7Q94xlAC17MyBvu6yd34oJwjX3mkPxHNcXel urQfIPCBIhjJrUJpDZLvA3YMOabRrta+sKa0syur1nYGj1FfWgJMI4EfCqIo3AcozXDO dsGskfg7rn9qoEjPXyBM+gTLzo68laj9pKRG2YzyZZrC5rCy3JsXm04HqLG86qlQQF8V Yso01ub2NvBBTfuO8ODlt2LKSFnR/zK2fopgGob4OUQ6m669MJT/0jOatdBAfdSrIFPd IjhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724924533; x=1725529333; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=g5Mg16IGZHR1AU9QEpDlBdQnYhxBBYTm7k573SZhd6E=; b=dhl/16Q3NvnYhVJnKa1tzdHWgy2AM4puefFJweryIPC6m/qNHnWrow6OxaxqnqXbtt 2mganZ1L5gPGPo0jZXGWPWUsKa27LhMMvcIbfhFaL5wpPDzzBmFr/kP0JEzxPhXL7AOg zSPr/DJ3XGpEihkBZYNpxrzeHvH5OBvwMTAuAcT2TK9y96ht5C3ktpYtqREnhhZ1pyIM XsiRxtItunxqDHqRFR23Ghfv4MV7S1g1kyvn7cPjrDqBIm7VsmyP4VUGusQPpTBERTao JVhxuJzBVaKMTvSK5q+hMS4M5e4/eLexkNJ9tonCGEZhttz09dIMt8nYma1aB0tABBah rSzA== X-Forwarded-Encrypted: i=1; AJvYcCUQhFZvDq9zQb4evz7I4BAs2/3JeaRYhDHDhZYX0NPuxMmRnBsjTho96KEgP4x8F3fJ/v0U5hEikw==@kvack.org X-Gm-Message-State: AOJu0YyQQ/c52dxLJEJv5MGSV5et/LDwA/T0pjY4n0WgVZmfJcbBMrmI Q6DtmPJs1ciAGsd4VX84107i4eR6ofmy7TWy9posODdaPRssL/p1 X-Google-Smtp-Source: AGHT+IH9gN5YJTH71LWEmw/LJ7x5bIsw0qExseukjNX/GJNfnDKLYSgNbTmWWID5aEYOg1bUr9eTNw== X-Received: by 2002:a05:6a21:9101:b0:1c4:a49b:403 with SMTP id adf61e73a8af0-1cce1103f2cmr1698490637.46.1724924532411; Thu, 29 Aug 2024 02:42:12 -0700 (PDT) Received: from [192.168.255.10] ([43.132.141.24]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2d85b3b7feasm1071382a91.47.2024.08.29.02.42.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Aug 2024 02:42:11 -0700 (PDT) Message-ID: <9a6e3169-2ebd-47a5-b2e6-953a8a6730db@gmail.com> Date: Thu, 29 Aug 2024 17:42:06 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 00/21] mm/zsmalloc: add zpdesc memory descriptor for zswap.zpool To: Vishal Moola , 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 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> <66ce5eed.170a0220.387c4d.276d@mx.google.com> Content-Language: en-US From: Alex Shi In-Reply-To: <66ce5eed.170a0220.387c4d.276d@mx.google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 22BEE1C0009 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: yfabph31f1958pgxatsmkmxnxgx7ead4 X-HE-Tag: 1724924533-165061 X-HE-Meta: U2FsdGVkX184+bNGwGm87k8s/7aX0ws1UTC8WncY4wWsJ6kx+pMiuKEo5qFg2OuBu7pnTBrIyPf7Tmh3kmsS1zdmWC45Xcc+a+IuTmCPYnMVd6Pk0rxUvTJGXSxdbFbYct+QX7YH5wEYKGzrJYG0v6oq78Zpk9IKjnvkIjJQ5KAIDwgvAXvlvIETLPuMdqmMkltL4GuyPYQTGzVH1mH20YHPKMI8RWu99DUWhuCyck4Cww+icFispnUXMB5o3GRCGZaG9vM1+K9dpwVfiWO45k2q8P4Z3KAq0EFdcLMEgevHxBNN6jW5VObfNxe3LA0cqzJTeFiCNImkWwWeEsIZkt3PZvDjiLJKc2FQstWOC90jH0KjJaFr4jyziMn0eFrte+Y1TxRKbYmzfMfxnUxIzFg0gIO9Ix0+Vqyb/ZIkeTrWfAPrrm5ZSE85MF3Cd3VbjQGau9wEVqUdAu8eiNCMzp12ubICAeLS1ncuyocUbp5+oZ6Sq/rjj8p9DRx6Y7s2MuBQQWVMlH+NSKxCxAgtfEiNQ9T+PezOWk4nxyjYYLnD1hCXO1AtCwcZ/pp0qqPhoIIQcKkiD9W17ZEzH9gDf2jFafKinsjBnBssSDd36k3v+VX8gUkitkmYaUiikDcxaKdST53oQrh32vvSS1FrbFZfUYSlR5+H9/Nm/XSf4KhRaL2wWg1MUn1wYidaeNAADCxIYtFtoKYrB9h1fRhAcRM5ta/Mx0bppoZvoHwRAoxHgG/m3GPcuJlU0pTg9CuJEREkNTYy5xUYYu+d4bEviwTsZEEv8IPKaEMlGlkKPwwoWlPfn1PfrJ92kuXSHZfk9e69av0GCykmvUPYy3Pw477MT7IEc6W0W+hCrLepnWr6FwXxDncbGKy+zMJmWIhB9iOjLuvdh8pKgeh/g1MrBpdDmsnGJNEah4WqgqNo/dvAGJXBYHxrkd67tCev7HU7ZHsxnGNKyspgAtJj+4Q +XMEZyIp t2oxorwyZHHjrRqZR7I3JdGoAwpQJl68LpsbeFK/XacRsxV1qkFjo4IDc4A5F4jJEXHSRMhcKqUj1Vk3wIofaDP9+cm93JaQuZRwVN0SmaU2GdNLwGArA0WHqmW+FCPW3ZYDMsG2cm9UZvaSUCuuKGwv7nHHtZNxDRGYhuGciFdLZyKHH4/2F4HLvGbStCT7yRYU+VNrAiW0G1jS88HtOH0LpMm0ZMSXoV2r6JCw+2IRHhHWLFAZG9qFWz6JW3SkDBTaVaOWf6j8OtPXKJfDjFwW2QGUdiAA00kxZ/oWxgIp2LVeJc/xbOd5VRWTWljL6lMeZ7INXzSf7mm5ckoeSwY8dZLWdNezxl3To1QpUNo1spGSz10/jzVWsAjT4bMMRDvyqWU0t1XsMTQ813DWt+7Fyd6/JKjqV2nr4hxSvHQ5AM3gDBUlbe84ABDFNZYt64OOJBWt4yG6bIj8QVw25G3uF9esz5mHusFAN 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 8/28/24 7:19 AM, Vishal Moola wrote: > 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? Uh, correct me if I am wrong. IMHO, regarding what this patchset does, it abstracts the memory descriptor usage for zswap/zram. The descriptor still overlays the struct page; nothing has changed in that regard. What this patchset accomplishes is the use of folios in the guts to save some code size, and the introduction of a new concept, zpdesc. This patchset is just an initial step; it does not bias the potential changes to kmem_alloc or larger zspage modifications. In fact, both approaches require this fundamental abstract concept: zpdesc. So I believe this patchset is needed. Thanks Alex