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 136F5C76196 for ; Wed, 29 Mar 2023 01:33:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 74BDD6B0088; Tue, 28 Mar 2023 21:33:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D553280001; Tue, 28 Mar 2023 21:33:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 54EAD6B008A; Tue, 28 Mar 2023 21:33:15 -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 4204E6B0088 for ; Tue, 28 Mar 2023 21:33:15 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 11CFF140446 for ; Wed, 29 Mar 2023 01:33:15 +0000 (UTC) X-FDA: 80620212750.24.2D1BD5E Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf19.hostedemail.com (Postfix) with ESMTP id 4335C1A0011 for ; Wed, 29 Mar 2023 01:33:12 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=fEUYlTeI; spf=pass (imf19.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680053593; a=rsa-sha256; cv=none; b=wTacahbpAlXmMrRe31geNqWrbSTcvPe8RFSM03H2buoC71D+vMxcnEIQ8d1e6biV6OOGns BRcEwvfUUdo1cLBs5rOxaGYp2dUDTpal8OWiiqnVuAnXkBQh0NXls/16Vt5NeJjhOqNncF Sgli8PDyliPojAY8ISHadB9tQaNm5tU= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=fEUYlTeI; spf=pass (imf19.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680053593; 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=Hp/EAHneSmlNx3kydqbcsck3Nl+hxJQgZq7q3F+X4kE=; b=rlt5X8DGK+6bqGbKj4dN55toR+sfUzFrul3dZFVc5838TpcQ2mxUcrUb2XW9I77DU4ej0+ LOvniKD1qD6QlMaYZPddgatKNX4haPZ+EMl4Mzc2QV4KmacuyOF4xyD5gmhjBHkgbSVk2m 9sd8jGxlHsi78pIWlg/u7tOUIowrwGA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680053592; x=1711589592; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version:content-transfer-encoding; bh=26L3/GE6KheUrOvUzcLkEoloBHhUpR8FWknXQO9lgZ0=; b=fEUYlTeIFtEsODEfNqVREFuZXBVAHBhZ4/xtrZ5Ms5zlNnyXfygXggfx drtfb06tcS1+aqzWsF/DXI8ZVuuZZzGQWy7UgZZwvJfyyMcZZdDGD1opb Hf7ZNA/79FKy53jnivfkZIfNGIfRcUsHE1WAQnmid8lRl+PTSTCbaj+ZS UuglYSvEe79vlrmQKnSdFAh5NS0ondRm45gwUF6eB0XAMS34++RrWHz/t PVOtjIZCxAkmSoAazV5zA03uhV5EkSXgXEVlJxabSQfo57PVs3vXrMLep AP8mwIKH/wJ7IYuEnP5vH3DGvIzolY1zemzeYlvhjkNpNguDIGVxWBQZv Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="321143883" X-IronPort-AV: E=Sophos;i="5.98,299,1673942400"; d="scan'208";a="321143883" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Mar 2023 18:33:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10663"; a="748608360" X-IronPort-AV: E=Sophos;i="5.98,299,1673942400"; d="scan'208";a="748608360" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Mar 2023 18:33:06 -0700 From: "Huang, Ying" To: Yosry Ahmed Cc: Chris Li , lsf-pc@lists.linux-foundation.org, Johannes Weiner , Linux-MM , Michal Hocko , Shakeel Butt , David Rientjes , Hugh Dickins , Seth Jennings , Dan Streetman , Vitaly Wool , Yang Shi , Peter Xu , Minchan Kim , Andrew Morton , Aneesh Kumar K V , Michal Hocko , Wei Xu Subject: Re: [LSF/MM/BPF TOPIC] Swap Abstraction / Native Zswap References: <87edpbq96g.fsf@yhuang6-desk2.ccr.corp.intel.com> <87jzz1pfb3.fsf@yhuang6-desk2.ccr.corp.intel.com> <87fs9ppdhz.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Wed, 29 Mar 2023 09:31:59 +0800 In-Reply-To: (Yosry Ahmed's message of "Tue, 28 Mar 2023 14:44:27 -0700") Message-ID: <87bkkcpckw.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 4335C1A0011 X-Rspamd-Server: rspam01 X-Stat-Signature: 8i1z3h41yjjwffxcxikca8nzuxhjiudd X-HE-Tag: 1680053592-69358 X-HE-Meta: U2FsdGVkX19b0FrCK23r/aL57xOfkvlK/+aup9MSZHudGlPIoJgmiZeok56HpPA+XxntlSQez2X65CRgRZQ5lVhoxo/86MB3XRkOIFSBcJsDt4HkrKBRV+nvsYWtymTA/UsYdb/6DzOQmK9ms5ZRhYgCdPNanvidCAGcrakDOoz2KhFqdkjAIGbZ9mzBJjG0rojircFxSvwtgjAVBPIEM+SFMc8wybO39Ae47FJmW99OqMtyCqW1hP47OnZs3ee8HHq5dUQ5md8VkRArPc5VzQ3D0GJNdV+AF3hZrqSPcQwARGhfoD3gNdSq1Yv5UWEt2y4cKXQDigjekA0RpamYCoOCpH9z0mot8e8hqZnK/7wX5FA4SC9lmgNcXqsAiAZ3x/MKOhilA/Xt5FssfMoMldhbmqOLXUNFx+COZo/aQInSMBleB0vk8Fa5cNCQrqk99LBpD58rG6VnNCj/Xfne7VGpyRi6PtzovLNh7S+JFQ/HBJFloLdb1iqC2ilgedvp/E3xsv4yyZUzjQwwmy7lFgM7rs9abhUxI8mpOOINd5vvrBJlhlVOXZ2ahLjXcJKAPLksk69H1MCuHG/V5PK/D+4MDpT2+Vp4KoGuEUZygI+sX9aa+U5wZnjnxBDWCa31zdMJPqlhsojUw1MH0iJjpLmOWBbSHaxpEUG/+/jvrexc2C/cB7WrCGS4DnRViejBCnzP64p3ukdCSskP1Ve6K+4MXtMWUc30QkF7gAqL7FCnXNhQUckm2jrqaGgFZ4FO93FM/YbfAa2FEQGzHPmzUpNB7DCBvyQG4cDmcZAsOEwhQ4qgvF+oiCJgBQTC4XG7wLeufHK+/NXt8XiRIuusWV7b/BH4XWABONUD2m0pm3CF7Dg+IrzQbP+XrvXZowA5cTgp0q7rZpN732mF9C3fGwa02dz6xhpwG5wM9iOaLchjzNnfht6d5+grFHag7/VrPRirfR96Lqudzk3soKl Hm5cx+ze pXCecTxTFZ+ZxIWQZ02cucS0kLpJOE80OM4T/YK7yV/QXPUBDa3XC1yK/+OOC7IuNZdqU35ha4BK4hCrQanFzlRJKqnqoAnyTReIWHPOzBFrruOeQ5juR78ZqrXl1c4vBXQBOzeWhdrvTQMOe0HYDuZRh24KcfP5bObU3mXBgl7rCGuAdjYF6yTVXtbPT7MeXDcv7wcxNC/lA4YzPgm6AWZ/R9QJad+tVbet6Q6k2Q06jrmrf7M/t9wXdEs6Ii52wQ6DehHqjSAZ+hTHktFC508uATLuX6WB9FnJnpDo6vrkUTV0= 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: Yosry Ahmed writes: > On Tue, Mar 28, 2023 at 2:32=E2=80=AFPM Chris Li wrot= e: >> >> On Tue, Mar 28, 2023 at 02:01:09PM -0700, Yosry Ahmed wrote: >> > On Tue, Mar 28, 2023 at 1:50=E2=80=AFPM Chris Li w= rote: >> > > >> > > On Tue, Mar 28, 2023 at 12:59:31AM -0700, Yosry Ahmed wrote: >> > > > > > I don't have a problem with this approach, it is not really cl= ean as >> > > > > > we still treat zswap as a swapfile and have to deal with a lot= of >> > > > > > unnecessary code like swap slots handling and whatnot. >> > > > > >> > > > > These are existing code? >> > > >> > > Yes. The ghost swap file are existing code used in Google for many y= ears. >> > > >> > > > I was referring to the fact that today with zswap being tied to >> > > > swapfiles we do some necessary work such as searching for swap slo= ts >> > > > during swapout. The initial swap_desc approach aimed to avoid that. >> > > > With this minimal ghost swapfile approach we retain this unfavorab= le >> > > > behavior. >> > > >> > > Can you explain how you can avoid the free swap entry search >> > > in the swap descriptor world? >> > >> > For zswap, in the swap descriptor world, you just need to allocate a >> > struct zswap_entry and have the swap descriptor point to it. No need >> > for swap slot management since we are not tied to a swapfile and pages >> > in zswap do not have a specific position. >> >> Your swap descriptor will be using one swp_entry_t, which get from the P= TE >> to lookup, right? That is the swap entry I am talking about. You just >> substitute zswap swap entry with the swap descriptor swap entry. >> You still need to allocate from the free swap entry space at least once. > > Oh, you mean the swap ID space. We just need to find an unused ID, we > can simply use an allocating xarray > (https://docs.kernel.org/core-api/xarray.html#allocating-xarrays). > This is simpler than keeping track of swap slots in a swapfile. If we want to implement the swap entry management inside the zswap implementation (instead of reusing swap_map[]), then the allocating xarray can be used too. Some per-entry data (such as swap count, etc.) can be stored there. I understanding that this isn't perfect (one more xarray looking up, one more data structure, etc.), but this is a choice too. Best Regards, Huang, Ying