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 7F247C6FD1C for ; Thu, 23 Mar 2023 19:50:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E81CC6B0071; Thu, 23 Mar 2023 15:50:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E31ED6B0072; Thu, 23 Mar 2023 15:50:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CFA9C6B0074; Thu, 23 Mar 2023 15:50:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id BFD206B0071 for ; Thu, 23 Mar 2023 15:50:05 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8C5DEC07E2 for ; Thu, 23 Mar 2023 19:50:05 +0000 (UTC) X-FDA: 80601203970.04.402AA7E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf28.hostedemail.com (Postfix) with ESMTP id CDDA3C000B for ; Thu, 23 Mar 2023 19:50:03 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Y0lJv9g1; spf=pass (imf28.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679601003; 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=/oIH9CtgEE8pyQieMuMB2axTpm1HIsFI0sTQXu2sqZU=; b=JscN+6/9Vr2HT1JotMV7mg1S89kFP5Y9XyW5hrnAnXjrRAnC0MlFtcY0lFNmDbX8zXDHrT mgsz00A0phO/NbPDGG7Q+qT6LrwXy8oFTkNRVORIYc1enAgCrzFgimOisZeOlAWAJza6OF 7bdTdUuB6BdfPnEUTafS9pIcsrQdvto= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Y0lJv9g1; spf=pass (imf28.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679601003; a=rsa-sha256; cv=none; b=VSz2XrQH0p+5DZEDeYjazI+WaJEMfh1olZQIh/iH0dGL+S0Bs+A1yDJIZBgS04b0oCK3nX wt4HrK86O0Y+WHkiv0fc7PPGAqNnm27P1o6yi1pE6lfyHLjzTtfg8Ywm8PxL5+Xz4Dvo7t jN6cUMbMrlXdQlVn/kTXDQXF7W9mJ3A= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B9DAC6288B; Thu, 23 Mar 2023 19:50:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F53CC433EF; Thu, 23 Mar 2023 19:50:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679601002; bh=AjZVhTTUn86ojMdS5I1glg/RA31TMKVFS+IrFAAzmd8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Y0lJv9g1JW1H5rtsenGIeXlO17IAxQ143L5yN2WfD0o7swZIXRRTJjiqY5DAh+u4l 9r/N7jL93oaS43/TveHINGX03BUT95Z7JBGU9326H3ELYR6O+ej2epLsPrfIMVuUl7 mTh/+chptvufJTLdFcI4PThdD8NqWF3J/6B9wKFJ/7zDIlPESJCZCd7TAmzMUeXQx/ k+KQ1ZOC5H5phaAVTKaLTJg9HpA9lKaaVtNpsum1vG3CYppkdF40c0FWJVASl5vzct Cb0h6xSnemxHx/ETPhwCu2PyIcvNaWf7TN9IXQyJ9LP1En/v4DAd8vo2KPEFJsXMcR xLMR1ntEPdRPg== Date: Thu, 23 Mar 2023 12:49:59 -0700 From: Chris Li To: Yosry Ahmed Cc: "Huang, Ying" , 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 Message-ID: References: <87bkkt5e4o.fsf@yhuang6-desk2.ccr.corp.intel.com> <87y1ns3zeg.fsf@yhuang6-desk2.ccr.corp.intel.com> <878rfothdg.fsf@yhuang6-desk2.ccr.corp.intel.com> <871qlgrm5j.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: CDDA3C000B X-Stat-Signature: 5tcyzo3zzjz3t3b9zufmo1a49k85iggo X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1679601003-134223 X-HE-Meta: U2FsdGVkX19UWOiDQqpzJ5/J3vSP8ypQmmujUo1nNaMJV3zRl3A5SLd1t5V1jn8Fh0PsQZA5aG0xyWniP7sIqVAk/diXvofjdXjfaJgvux0+WLyU1Iyz6scJwQTezPGWLN1wIQSL61RoWy1gWPFB0cQK9VH/TWKdsnavviAU3cjaeMl8MnL7D1e2G/8zF+9wG0DoqS3CpCxNIHtnLEE/PkINHa44DRGhAPf0TWhcEdT850DJR+02p90rX3Sx9P68RfoQE/HkFNtFTf13fMZZimp+bqdyuWn7Xub186xsIKh1Fp7WzDL66Gzm8Jng8f0Xv2tXcaCPyiK7dAyl4KTqRs1t95oyOjpldZ7mv8JsAfvEvY+z4yRbdt6KekR7MdPl+WXzVUtR3Zbpk3Wmm7L7llnTJjKV+PO70zsmKI01JZRT6ga9ph4egWx7KirHXoNK+RPXHt28E7ZtxMXSxMJXjANZ55mg5Zgo/4BzC+Lh9tq69HX0YsvMA2DLss2d/1r6+tFq2iMdCQaCD06u2q/wMlTSgc9J0ov/hXNWVzF5jHIgOzXaLnoY4uVCTu2L/Pvvt2R3fRp536Y5C9jSyfQxgbZW2we54jZ4IJtJa5laAmXuLZJ5E/TSFIM4+UUvZSnxoIIkqnlmorBq1++ESwT5D252iFCuhc0YNDej0qiEmakNboY/yfzxjY0BTNxSKsp8tdny4Eq+M3tiZ0yy3VHBH/kJ+naN19qcbsjcQWl8OImy3OYyNAATRRJC3vSA9QJBTp+XS5CG2ONVbvVNEMK7sDW259PC8W/cAYZeBUYfG26WeIBF4Kkr1I+71H6ZyRgW21AHZgMA0bND2uNj4aHG+uUBDSvRgry2E/UWDBuP9Z6gk+xhggzlThUP2r3OITWfRZH4e7AgXUEr4cWEVsc6vv2P5Yy5ZRf2k+jGcXKLUkJJJfjkxD0aZ+zqw/k4uiOL+KYgd78DbCtrrasmewu 0RQ9gREe K8uAVWFwkLBov/yvwL5nXQsGvYbhpM+vzqnngnBtoLlvdub6Nss9bBt/Je7IH92o34HsaYNoBFH64JiSG/NdiNKT/zJyL2YmHriOTzxm4+N5LCuPe93SrxjClVydbWk6ZgA5WohEMxmq6oeGZnhMGKLh30+gfTs1C2eq1CZBim3rF1ZD3okeuImDidCvNJwj6h5JCj7ektv+fiOZSOsccHwAX+1HDrs9Ugo9Thw3tZBGw7VfKPMaz9s64v4BwTM3G6okVUfcQPui42+13r0+c+lcrK2Bh8cGNhxa+r6zRFL4/K8HU6gv3ZZExHw== 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: On Thu, Mar 23, 2023 at 11:40:35AM -0700, Yosry Ahmed wrote: > > Thanks for the clarification. If we have swap_desc index in the PTE, > > let's call it S1. I assume S1 will contain A1 and B1 as part of the > > swap_desc struct. > > > > Now we are getting to some very interesting details. > > > > What is the life cycle of the S1? Does S1 share the same index as A1? > > The idea that we are currently discussing does not involve a swap_desc > struct. There is only a swap ID that indexes into an xarray that > points to a swap_entry. This swap ID and the xarray formulate the > indirection layer. I see. The swap_entry is the same size as the swp_entry_t, which is unsigned long. > I am guessing in this design the swap ID is allocated when unmapping a > page to be swapped out, and freed when the underlying swap_entry's > swap count falls to 0. If none of the swap pages on A need to move to B (yet). Does it still need to allocate an entry in the swap ID xarray, only pointing to A1? At the time of swap out page into A, we will not know if it will move to B in a later time. I guess the swap ID xarray look up always needs to be there? > Moving a page from a swap backend A to another swap backend B should > not be a problem in terms of the swap cache, as we will add it to the > swap cache of B, modify the swap ID mapping to point to B, then remove > it from the swap cache of A. That means when B swap in a page, it will always look up the swap ID xarray first, then resolve to the actual swap_entry B1. > There are some concerns with this design that I outlined in one of my > previous emails, such as having separate swap counting implementation > in different swap backends, which is a maintenance burden and > error-prone. I agree that allocating the swap ID and maintaining the free swap ID would be some extra complexity if we are not reusing the existing swap count code path. My other concern would be the swap ID xarray indirection is always there regardless if you need to use the indirection or not. Chris