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 C1FF1C3DA7F for ; Thu, 15 Aug 2024 03:50:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F2A5D6B0083; Wed, 14 Aug 2024 23:50:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ED8B26B0085; Wed, 14 Aug 2024 23:50:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA0386B0088; Wed, 14 Aug 2024 23:50:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id BCB426B0083 for ; Wed, 14 Aug 2024 23:50:45 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 6EDE71C3F66 for ; Thu, 15 Aug 2024 03:50:45 +0000 (UTC) X-FDA: 82453103250.14.B9DA2CE Received: from mail-oa1-f50.google.com (mail-oa1-f50.google.com [209.85.160.50]) by imf23.hostedemail.com (Postfix) with ESMTP id 7DB5C140005 for ; Thu, 15 Aug 2024 03:50:43 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bh4GD5bk; spf=pass (imf23.hostedemail.com: domain of seakeel@gmail.com designates 209.85.160.50 as permitted sender) smtp.mailfrom=seakeel@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=1723693786; 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=3Z1CUzmhClafRFyxU4gxwwLyWq/ScaI+Gv3jC0Z1Y5I=; b=hjiMnW43B6a3f+wT0DjT5fGjHcLckqhqPJErMaa4JKfiomxoiRoUOi+7cv8tfszfWK58rv xi2RUQfpIRwT74VjOLcRVZh1dDmXb9wLN2k7jv/xmD9wIvD9I31TMgzWXAR/eDjYTXinEh BBF1aHZNO8wIrJuDm7QwvhEzKoBlfpQ= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bh4GD5bk; spf=pass (imf23.hostedemail.com: domain of seakeel@gmail.com designates 209.85.160.50 as permitted sender) smtp.mailfrom=seakeel@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723693786; a=rsa-sha256; cv=none; b=6jD/+KtZAEDFVj5xOnXbRKQiSEsimf2L8OJAVai9J4ucqo1179+PHkv8u1He2Ki5otKY/W ycZPh4h1pUTVGmtO7aZPIGpr7lHnCvqJ7FeKt4sAdsRnpgKIeL0uc7ox5lE2ZbKLDo/q5x dhkWgoCJU84ATgmdeWkTq4saeeTE93I= Received: by mail-oa1-f50.google.com with SMTP id 586e51a60fabf-26fda13f898so390240fac.1 for ; Wed, 14 Aug 2024 20:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723693842; x=1724298642; 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=3Z1CUzmhClafRFyxU4gxwwLyWq/ScaI+Gv3jC0Z1Y5I=; b=bh4GD5bkDpaG/mxifYRzQbUi1GSBIi5VkmpaSgVPUnBH1vGEr3coWlT2wJ/1vIubdG YlQgMqEDutDQzPybRDvR/0lcJesbTrZ6U64N4V6OgvK0sn/a53bMmvUohPRP82sgtfbX To7qVp2XXtOqEBKIZwf1OQaDZKNyhuMh71kafco5xDGiyafsF117ZhTmda9t3U7YHjbJ Q2ID7+cOS22JfVDHMVCOvzYwkrj/ajUT9XJi3YagvaGOygVtzfi3URAPLNyoOHjpYCqi HGJpbjbl/9aSQ2JfdP5TnEVZ8mg17Vm9cabF79GZTa5ZtQi9pi1AuRur+zcFIpNWXZkj a2mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723693842; x=1724298642; 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=3Z1CUzmhClafRFyxU4gxwwLyWq/ScaI+Gv3jC0Z1Y5I=; b=LC6jHgKNX8K5WcaDlHxD0l6WX/CP6moUKtCCqUNP3yhdgaGLOxFpCBTdhPJo9vfPbS xc8lRfYC8QO2voAeC42L4gOmOw4KIzdYD7LSIpnivPMeMi5whE/UZ0PLERInnb5ughyS k1jfIxiO1gc/GUbhkQ0meWg2vtz44zKK7u8yHT+ji5ODpfxrrlr4CMg11sAlewfeFFQV kUX/YtcT9MA0MUQOi8V5fSkzACqb+cU3d+2U7wlbQT5krbWEhYEcvcv2YWfpDowB0c04 3w4TiUOJwlLIGtp70TsZBXaOGr+mNY3f6++0CDELwfMwr7TceInYn6vSy6ejOBagVn0L JxFA== X-Forwarded-Encrypted: i=1; AJvYcCWTML0g8HR6EVsfm7Ub3rbAXGjQNJHjffkf9OmKqqa+sV1Im/HhD15bRKmY/bveN1lSMppN6lJvFzjxpHek1WMubD0= X-Gm-Message-State: AOJu0YwNDYu8NalQfSuP5cJp0L/U/ZgprK9uNKWOZJCjBPHbiTh6u6rW w+wkY9eY6EqvJ72OOtLbI7beZuR1SCuMMxe7tsMA4RYpeHB0b7Rk X-Google-Smtp-Source: AGHT+IEm9NdNcXdysuTBvciuS0AClLfm6nlGkDSMqK2k7C/V8Xjjm7HW+mu1CEt7x1NizttMQG6pSg== X-Received: by 2002:a05:6870:e3d3:b0:261:446:c405 with SMTP id 586e51a60fabf-26fe59da47dmr6119502fac.4.1723693842498; Wed, 14 Aug 2024 20:50:42 -0700 (PDT) Received: from [192.168.255.10] ([43.132.141.25]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7127af1f2cesm307857b3a.181.2024.08.14.20.50.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Aug 2024 20:50:41 -0700 (PDT) Message-ID: <5f785814-0be0-407f-87a0-4bfb4041fa2d@gmail.com> Date: Thu, 15 Aug 2024 11:50:37 +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: 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> <20240815031314.GA12106@google.com> Content-Language: en-US From: Alex Shi In-Reply-To: <20240815031314.GA12106@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: 7b3ihkw7g7x3c5ph3eb5whanhdiabucc X-Rspam-User: X-Rspamd-Queue-Id: 7DB5C140005 X-Rspamd-Server: rspam02 X-HE-Tag: 1723693843-904622 X-HE-Meta: U2FsdGVkX19ayBsBA+FdZsgYgr2c7A7ZKn2d8W2SkMnAYy3CFYRptSuA6MNNNsk/xBNzV6cEbFlJr4jSqVIvvrir1udhMd5B8zoFCulBpOufDn/7SUoFDvbAJLpJ2fwGfxvw4MTImQ8tZBtKh+r+spka2ulxi/114U5BehnaKpFu4kXD+AQreLE2fyP1qET/LnZkWcei29SEFDLm6v9aX4pKELHcLz0LL0Lfsy+qqK+96ezYO2yJMs/0eTXFtmvL81P1vwa4r6j2S7OiYShNBdY/vRv9vffXd1xIfPpVF73kKYsU2G83kTlFfoiAuS8AspB8whpYMxRkcAIX5ojPRe0chMxux9r+fYWLCeNVdlDBdDzD9oNwDAOGgt/x7+MPSbLR0qXXeyzfuF5/u4U5ouhwRdLxPxTO6sIsVr8/xJjiMA60vy3pzYkkhC6Q4/9jnYmhoOEC4bO54jSMMru6XdoOEzS7QEhd7WZteMIoiiaBldK9DV36X/imV6p6gggKF85xviNkTtnlLEuChgxFyhK+MYk2PiIxIrPbxnL9VweGL7BKioWHK6qtiy/9alScqoz1Kay/PSSQZSk/oEAU11vdxzxvqFV7m0UzZ9wADWM1SqxQd7FZxbR1fz+jlaEVgfv1GkYxPLuAAx4lt2MHQ3xtPXhnH1djqwULMy7/8p+d/fu2JGBTNkY8vtSZFV0cLXfszqLc9RyNxUEnvcQ6kzfkxWMfB+qXcxRRJ4atXgCpwOacU5FhrT4b+p0BsgpN8SMbIOOprl4GfOLdgRJ1GnrYLj4hx0LqUQvuEppjnKp4pFWJ6UCi1Qpd9GmL5QXdffOdouuV0i/ySq1Q/Um0dMCgDatW19RuqGHCBy6mQKwT0BFtQMVunDwhCm6Z1sVZ+aPGrXmT3o0Uq4dfZrPV6xX/XNend2mNDgKm/QH0UJb4ywx570SN1I2GqBnb6sx8ATUwsRpzdDe6y/r6xHP HX91++k9 VeAf72+8SOkAEqmRq14/yfoAHA1Ro/eYa/GiGyu74hujDoX+ERCB5YhMdwuGivq28WchCc9YPRnpEUsZdgbYUMlovmlC7FYKda4fB4A7p8Eboqr5Hl+K7T4JO2K6O5JP/vCDM5v31Apv/2eRiLUbCYJwM0utGveWG/Q2uQj8E4Z+JW4uHL+ziNDgqJ2yRIIbi9hu4HF0Y4XqKrDlC3nUE6ylqNNCGSZSb6rk/NhL7saot/Rl5mz64Mf85h40Kocdcmnp3ILIZUoWGziFMymvA66SkXZccisnA0f9HPvqGW7mcjhUcyM7P5GVvsmOiIa5WTWlCH+Rd6ZORkAgdv5kdoSSSDnGYyiQAMGsw284aPuC4rJGCNXGeamCJ2dGI5NtZlSCI5OqA4pihK+ccnIHV0qpiG5TSxYFlNfqrBAN7xP+HaJLWD344MOLUrGd5CQ3SmmhR 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/15/24 11:13 AM, Sergey Senozhatsky wrote: > On (24/08/09 10:32), Alex Shi wrote: > [..] >>>> 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. >> >> Thanks for the suggestions! Yes, it's a good direction we could try after this >> patchset. > > Alex, may I ask what exactly you will "try"? Hi Sergey, Thanks for question. As a quick amateur thought, the final result may like following, please correct me if I am wrong. 1, there is a memdesc for each of memory page. 2, we kmem_alloc some zpdesc struct for specifically our needs, like zpdesc.next zpdesc.zspage/first_obj_offset, these current we used in zsmalloc. 3, there is a gap between memdesc and zpdesc, like .flags, _refcount, .mops etc. this part is still unclear that how to handle them well. During the 2nd, 3rd steps, we may have chance to move some members from zpdesc, to zspage? but it's also unclear. Thanks Alex