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 4EEAECD4F23 for ; Wed, 4 Sep 2024 19:51:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E1F86B045C; Wed, 4 Sep 2024 15:51:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 792406B045D; Wed, 4 Sep 2024 15:51:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 60B186B045E; Wed, 4 Sep 2024 15:51:52 -0400 (EDT) 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 388496B045C for ; Wed, 4 Sep 2024 15:51:52 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BEC14A042A for ; Wed, 4 Sep 2024 19:51:51 +0000 (UTC) X-FDA: 82528101222.17.3C272C9 Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) by imf27.hostedemail.com (Postfix) with ESMTP id DB70240003 for ; Wed, 4 Sep 2024 19:51:49 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mbI1dpaM; spf=pass (imf27.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.215.173 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725479382; 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=SlOmg5zgF2+yf7PiIjOBjN942jtPLLMdWv+krlSsj6A=; b=JN8V3sk6IgRhOTZM79w27OIXnSqXgcrNUfG8sY/yKtQLAB2ZS8NlgCfrrjHsTYmd56tfM3 mA8fPLyTFLZS6d/xqcAYvYqeXLs+kzmYRtsnir7uFS620/gCoFrgw/eh/FQIRjPdCWaZHz g75qrMRUTvwzrMSNQ/3tE8oUhBWnClo= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mbI1dpaM; spf=pass (imf27.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.215.173 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725479382; a=rsa-sha256; cv=none; b=h1BcWc0QhzCJnmGFlcVFMnPMRnpog+uCz5URhZ/xlo4+p8KcQzaM2NCT7oLB0t0RbsMkpS /F5XSSoidB5FvxlaZkCAuob+mI2UI97NqYAaZLUz3e2lNBunF3+QTZGfH5i2F2d2QdJsuj gnv20GNLmXJ/YVg0Ct3VIMi9D0cIf04= Received: by mail-pg1-f173.google.com with SMTP id 41be03b00d2f7-7c1324be8easo845509a12.1 for ; Wed, 04 Sep 2024 12:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725479508; x=1726084308; 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=SlOmg5zgF2+yf7PiIjOBjN942jtPLLMdWv+krlSsj6A=; b=mbI1dpaMxGH1vd4LLbwzAPOdRNfWvI2Q2kWDuomEe1HveO2+xdBS3ato3wSbdDt99L aBqnpWrsNVA02QNScLIty4D4sd4RBRi51aaQOtbErbBV/H0BFGzI3Lcx3XUwYmpdQDs5 f5N/Cf01XUAVz2rjxaQRRhAdglD06zcAmJKigc8ePWUVUrX+tcIpIuYoTP0LGCAX1Vec XZudOpzhG2q+HHYXSWRV5Ae3oxVnm8Wxm7ToJV+yzPJueU+LDCcx3bb8F5eoenK6/V0e bLQwYgTy8EL6uBCO9PzafzCjeNyWeiXo+6j84XAekoDl/AxvmmivJDpgWpbmmLZPYJ7j V1jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725479508; x=1726084308; 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=SlOmg5zgF2+yf7PiIjOBjN942jtPLLMdWv+krlSsj6A=; b=Q989Vzm5Qd/X8muTtKrlV7LVtHvtUzEbQli5ksNS08q+tgDjcJQU1ZTHibVk6eK0oi +9Nra+SvDAb0AtiTUZWDrXMUsomsy25Yoshjga8P94hkPVI2v1Qa7//WpPaOO/0MYvW3 nfJtIGRD/tIB/4tJRhxOwVGwJi9d0nhbF4cWuebbZ4v5SU5nib2o6Hvhg7vfndyj0IfM xUf9uZrcpBaMFQFqmv7ulygWZZGf2Jw6gd0FcNMVktT7v87cjwKe1kbgJLwPbwy4zDin 1nyWRDrUHSAJuaLco28jgaEJ6omdcuZZw+d5J9mlKZIfncBaMFcRdtmEoY7/+RuihSDf VsEg== X-Forwarded-Encrypted: i=1; AJvYcCXVA9v9T9bC9arS9wqJAMSKk/Fw6Y8q/2JX5S/T2HdqFJ9DZJ8XV9Iv7ed79gr2T//S0h8FgX7vmA==@kvack.org X-Gm-Message-State: AOJu0YwZgZ5bpMmWQVfHaqSrf5Usu/u4wAjAHCa9Xe61NhuqClP314JS XODV/JzpG7dooxnOEu0cUR05dj8PMcb7t+T/lzQZ+DyG1cIgHUof X-Google-Smtp-Source: AGHT+IEEduUCOiywKQwIwI6xvxJTly9F9XAvRUraSNTzhT5RKwxVR3PEheBdkJTaYWes1HDYN+dOvQ== X-Received: by 2002:a17:90b:3007:b0:2d3:acbd:307b with SMTP id 98e67ed59e1d1-2da8ede7c4fmr5396846a91.10.1725479508281; Wed, 04 Sep 2024 12:51:48 -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 98e67ed59e1d1-2d85b0fdbd8sm14040061a91.5.2024.09.04.12.51.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Sep 2024 12:51:47 -0700 (PDT) Message-ID: <66d8ba53.170a0220.844a7.1d81@mx.google.com> X-Google-Original-Message-ID: Date: Wed, 4 Sep 2024 12:51:44 -0700 From: Vishal Moola To: Alex Shi Cc: Sergey Senozhatsky , 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, Dan Streetman , Seth Jennings 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> <66ce5eed.170a0220.387c4d.276d@mx.google.com> <9a6e3169-2ebd-47a5-b2e6-953a8a6730db@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9a6e3169-2ebd-47a5-b2e6-953a8a6730db@gmail.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: DB70240003 X-Stat-Signature: t4roprd8ga8zx6udjs74g6d8z1p3cqob X-Rspam-User: X-HE-Tag: 1725479509-381952 X-HE-Meta: U2FsdGVkX19Attqs7seaL3jU4CBj5pxynxwrM5Kn3sQ/TntEfjKxpS+xdB1NrVNrv7lxTKWeLROPt1MOf4dZwhr8IlTmuDZtuEG3hTG3dg6aVHqET72TnYuYCcGuUGRIVFiUi6yQw3Gj6C8TWIXhs6zyxd1Syb4ES5V8f5Lm4VZXjH7MnErm4GCLXtMdf7qLCFNX37f24OGKdxjg5LNBc9nNg1so5xrBMCU9SkJeJhz5jK6SDPXc7SDrrjxrX8MQDUBrCtFVaelteZTt6OjqUgAqHX+ECYuXsJUWeVxNjsPNNMJ6WhYopB9U/tJPdwfDos3eQNYnObO/awgVK6+eK8MuBnpDXSC81qhUSyVe1j2j3VpIkPFVPXr2q/TUo/8wlMfS/M3BD5TYLh5ZZTJ3u4t/Nn9BD5fMyi6UUI0iMlKl2/ywX4dtOf8CPMtYWNi/7feK780fLaPGG9alGnEa7gAj8el+UdDeYIcb95b9SW4U54sF5egUxDZIdHtW18w4molEmPiWGjwmHX/l9tBl3Kne7eQVEwyNvLepNTrNHYzKj3zEuv3ovSc8OscG+oL03Ih1UwGB/O4c4jC5meDik7Te8+szLKZDwfjZo8oogRLiuBkClk18YtsChc2lVUvX3/mMLXYqFE4N7RdzTaZZLsZA6m6Am7MaKE6QFOE+SJXP8KJ32fxWVXfbwIW93tnZrYK7A5buSfLr52XFOS0u1RGcqQuzk0fQUjvECdsPsFBeMG6xc/VvR7k+/TkGaTw6mcHo3sUctgRkvlxhdnyDXd3igEDmXtRXhYIkGNSys9luWaObcC7sX0L4fKTTe9PRxADQ6Y2YtWSYjgRpLXHFVF1QPu20KQSYe1ASZ7VRjRwLJHO4/C2XIIBRypYCfddNURqxvLeFMg9bNkUMMgKuTXdznbOAlDAvja+f8wU5ItGHlq3F+0xywPrZaooA2Ovhy7cg7xkC5cQcmzRiL8F J0xLbqx+ hC3zs3FV6LWGRo/IaNHl8BA7FZ/9RrglXY3gPslyS2ooNydlC4YNFMVdCGEXc15s5oMyMM494p2m813A54FciiI6w6WYURCoiwDVp+DBeQdCEDqRg3T6Wr4vosZgQiy63jye7YE8RYkp2oTIzRFEW5yGVfgetyqiFp2caryJ9Rxjcq/D7PFy242/88pNZUUChLSUZZMyVNlGyYKmzgqJI30JzIqoa0sVa3UwOO8sydeymIfkDmcf6OMaE0boh6e9tJvKgbjhPUY08ZlXM+jJIatcfATx/DeRiW0t+ttm4sfF/wd5WsOLYwfzcnAWAbE1lriNjkURhhlOUJLpDY7edyoBD7JR28N1xybHpUhk7YPdFkEtC4tHKHnPAgYeawUIRCCTt583mC9r9/06EEcyQljBwR2/dQkeGArdLxtrb183IwEJiwrwGFkqS+oDx7vixllXFroz/zWNNMDXrJ4bY/csUDw== 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 Thu, Aug 29, 2024 at 05:42:06PM +0800, Alex Shi wrote: > > > 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. Sorry, I misunderstood the patchset. I thought it was creating a descriptor specifically for zsmalloc, when it seems like this is supposed to be a generic descriptor for all zpool allocators. The code comments and commit subjects are misleading and should be changed to reflect that. I'm onboard for using zpdesc for zbud and z3fold as well (or we'd have to come up with some other plan for them as well). Once we have a plan all the maintainers agree on we can all be on our merry way :) The questions for all the zpool allocator maintainers are: 1) Does your allocator need the space its using in struct page (aka would it need a descriptor in a memdesc world)? 2) Is it feasible to store the information elsewhere (outside of struct page)? And how much effort would that code conversion be? Thoughts? Seth/Dan, Vitaly/Miahoe, and Sergey? > 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.