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 366E5C6FD1D for ; Thu, 16 Mar 2023 01:44:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 472A16B0071; Wed, 15 Mar 2023 21:44:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3FAE46B0072; Wed, 15 Mar 2023 21:44:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 274106B0075; Wed, 15 Mar 2023 21:44:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 10A406B0071 for ; Wed, 15 Mar 2023 21:44:13 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C430D813BC for ; Thu, 16 Mar 2023 01:44:12 +0000 (UTC) X-FDA: 80573065944.18.94F14F7 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf12.hostedemail.com (Postfix) with ESMTP id 95EB84001A for ; Thu, 16 Mar 2023 01:44:09 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ZJ5SJ38t; spf=pass (imf12.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.88 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=1678931050; 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=aRU5haRbDDEToKes61j68lQm9DcmCzBoyKb8VKsqh+w=; b=N9XXGNuwC0kr026skk/JNY6S8zCHikI3AOsEMKpKRumGF5afN0XOS5CGM9qZsKfAE3i9Y/ a8yNSFiFxCDnrlj+ZquwKVNzwWUi83uIwgvC0E5KW3rrgRk2OEef80nPF4ACYkHSeFjbCp sLYZ1Yzccw43yc5bupJpikYcqX3mEgs= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ZJ5SJ38t; spf=pass (imf12.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.88 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=1678931050; a=rsa-sha256; cv=none; b=0eUbbcMhiyRm/TTuVGXd4tBw7WFfJCVIstXPCYEFjYRxOQoFSD7MARi7oyBoXcscfb84QK Req8PtN0QaJ5AgJJAD8cOMPWhGOHLwzkldFGg8Kh6UB0we8ny/HC8I9JHvEUdvl1hyB2HT ZTlcZThFV/x1oh6dyDULokmzjiasJLo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678931049; x=1710467049; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version:content-transfer-encoding; bh=2uicWAdKlUNDmmPFWULz1IrecA03etdAkcOXf4RHmYs=; b=ZJ5SJ38t6zje9uIDiAHJSEJMaGNAkX8uQIXrahn8jhUfOjzTeieVkilf avkm100zUP4IEalMHpxaj0QaGHq+e9N7BDwB9bbWgfcg7RA42Haiz9vA2 rowXMFRPUYpd0ebsS+fSIUXdi9vfjxHyghCuhmvwNeZgfEJQKTic/FTzT insSf/bEvR//9UrnGp59sk+WPU2Z02yxxg7SQoTOjZ3dxXg4VgPCsLvlO 8UugZeAoWflN8s7sqoqdiG+Yz8YtmfD8ybLNjxRkWYb1DOBK9xGdjS+qY Dyn3KC4ZbB6RTc+QRHi6/qhBV7NfZSD0qZDIz157RQekXVTFs65UbK2wO Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10650"; a="365549952" X-IronPort-AV: E=Sophos;i="5.98,264,1673942400"; d="scan'208";a="365549952" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2023 18:43:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10650"; a="709897793" X-IronPort-AV: E=Sophos;i="5.98,264,1673942400"; d="scan'208";a="709897793" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2023 18:43:46 -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: <87356e850j.fsf@yhuang6-desk2.ccr.corp.intel.com> <87y1o571aa.fsf@yhuang6-desk2.ccr.corp.intel.com> <87ttyp78xx.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Thu, 16 Mar 2023 09:42:48 +0800 In-Reply-To: (Yosry Ahmed's message of "Wed, 15 Mar 2023 00:41:45 -0700") Message-ID: <87fsa55v53.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-Server: rspam04 X-Rspamd-Queue-Id: 95EB84001A X-Stat-Signature: 4xfbfkuqzwq4tmg1a8rmgnot9esxz6si X-HE-Tag: 1678931049-984443 X-HE-Meta: U2FsdGVkX19FRdehnI8usMDgInnutMoG7fqbTuoZ98DFpXU4vMCsDngH1SKl+cOjxZPE5OIQL3/i24pB11gX2HGY9/BU8UjcVKMMQVPVF4kjhv1QPaMh5Kr0HWAAQcImhTey2E/fbSrNC6igaECkqsOz79ASzzbef0yX1Sj9ejulTaxrrAWjFWDpSIZX75q4eZbbu494xyUVbY9WNG01nofG+hfoiI8/GsCnNsp2+R/azWWT6HVxAoKqajfArcd3NcF0ly0gqYlz0blKv2PR5wm+BLLLhmuSXetKSwAYOH2TBKUmguwxdjB7QNu8AElkfw8bR91DHc+QFbwHYrrIW7hIIuqRiBOmEqijkqUCauZe4KjacpQyUoTCnd+xV8WU1kxtzTM2Wyhk373zDWlk4t6SWmAgR0v/b2VXifmGCDdqQRcuSht7igS72LPhWR9X1+W9/v6zzdl+/sXtykkkur9Am7796EW/yL4txprcJWGVptNxpRv4cFJI8GtoXjKsRmezHNfVCXBwSypJiqvDmLXXDuM4ePrJ7v24tfW1Tk0n9J1OwZ9zkKVPW6t+x355o0nd9Qd+LIfsQkGvcWleNsXdJ5z98Ih33m9zdp3e/Us3vjoWVoM1mdkU/AMUnLi/VfGUdRAcZjNbIp2GFECIV3MQ/oCMRYUGu/DxUJV1pD61bqcDVBld0eaFYnAVjXhpe7kwVYq3pIJTOhRLwPnVco8GO956GptltFFt7zj/eJ7MSLMjh5Z5boxH6aK9HBzj9ifJMj1U44by2zJGykSDNwBHXrk9NciOc/JWVpZ71kNik0zjjCf4OynKgzB0whYueU+TGuG0mlyCUY5JXMsW+BHJi7XOGx19kAuQSJZVJrR/1fPjxIxICVtOnVTAfqaR1LJ4kBci3G++Q31zDI2Blx/aG2Mv+feia+RijEf174VGM/8R0Spt13brmYF8polmDdrfSZKEC3onGF9n+rT HkEejrgT pYOPNDEQOl7NZ008AuDusXqnEnQ1OwAiyc0TqSO15lRFQXYEfT8w8NQnc2JlseD/LXC5EwcvJfWVFSy6T2IQt4RrNT1LWjnYJGQ1dwbsuKWN/D4FkhxbwhyV0PzaNt1Nfa5RrlLHfMN1F6GUSFdUYKBLosNIqtEEA+CO2cyVr3oWFueJGG5c2UXDLfP1KSdlQGd1g1uI69j0SMxwCBGXqe4pfLJ94yssw6s1KAkOGmOpwwSg4ELYvO+zfFj13ZmhwpooQy9RFwYImwTI= 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 Sun, Mar 12, 2023 at 6:11=E2=80=AFPM Huang, Ying wrote: >> >> Chris Li writes: >> >> > On Fri, Mar 10, 2023 at 11:06:37AM +0800, Huang, Ying wrote: >> >> > Unfortunately it's a little bit more. 24 is the extra overhead. >> >> > >> >> > Today we have an xarray entry for each swapped out page, that either >> >> > has the swapcache pointer or the shadow entry. >> >> > >> >> > With this implementation, we have an xarray entry for each swapped = out >> >> > page, that has a pointer to the swap_desc. >> >> > >> >> > Ignoring the overhead of the xarray itself, we have (8 + 24) / (8 += 1) =3D 3.5556. >> >> >> >> OK. I see. We can only hold 8 bytes for each xarray entry. To save >> >> memory usage, we can allocate multiple swap_desc (e.g., 16) for each >> >> xarray entry. Then the memory usage of xarray becomes 1/N. >> > >> > The xarray look up key is the swap offset from the swap entry. If you >> > put more than one swap_desc under the one xarray entry. It will mean >> > all those different swap_descs will share a swap offset. >> >> For example, if we allocate 16 swap_desc for each xarray entry. Then, >> we can use (swap_desc_index >> 4) as key to lookup xarray, and >> (swap_desc_index & 0x15) to index inside 16 swap_desc for the xarray >> entry. > > With this approach we save (16 - 1) * 8 =3D 120 bytes per 16 swap_descs, > but only if we use the space for 16 swap_desc's fully. As pages are > swapped in, we can easily end up with less than 16 swap_descs for one > xarray entry, how do we deal with such fragmentation? > > At 11 swap_descs per xarray entry, we are not saving any memory > (wasting 24 * 5 =3D 120 bytes). Below 11 swap_descs, we are wasting more > memory than we are saving. Yes. This approach isn't very fragmentation friendly. xarray isn't too. So, I think we should try to reduce fragmentation anyway, for example, reuse freed swap_desc IDs ASAP, or allocate less swap_desc per xarray entry (e.g., 4), etc. Best Regards, Huang, Ying