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 6DDBBCEB2CF for ; Mon, 30 Sep 2024 23:34:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB35A28003C; Mon, 30 Sep 2024 19:34:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D3C05280036; Mon, 30 Sep 2024 19:34:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8EC128003C; Mon, 30 Sep 2024 19:34:10 -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 94DFD280036 for ; Mon, 30 Sep 2024 19:34:10 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1E6C0120603 for ; Mon, 30 Sep 2024 23:34:10 +0000 (UTC) X-FDA: 82623010260.16.0CE8F16 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf25.hostedemail.com (Postfix) with ESMTP id 3BC53A0008 for ; Mon, 30 Sep 2024 23:34:07 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=UpOrmM83; spf=pass (imf25.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727739209; 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=prIeTSYiKIvJS+EE6ej8fL51jvYwgStC5lRUrm72WxQ=; b=jdM+/YxQAd/vwWoNLcMnH6xPDR4ls+wW5iAvNidxjk+i3MYtblg3YePzu9y64MDAG6tIB1 pFTqCEo4h2AFnP2A0LECc4o2bx/Uu9BZlulIP44aPVCCZxogAhxNANN9KlxaKyRN+VIF7w hHCZxktpdivmSHsrscgoncNCPyaD9ds= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=UpOrmM83; spf=pass (imf25.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727739209; a=rsa-sha256; cv=none; b=6uhxxLWXRZBuRBGWBTamySt6HU5C2ND4eLHgmUHI2iKWUDJhBx86vBuCL7bXm4QA9xol9K PTlzJ1MhzBxad1lbMzLJ2F35784xYSxdiFucTbCSz0w+9MqamjtH1JlP2x3/WI+En556pX OAPJbZDFr4tnFaPhmHZuqXJoNv9+eGk= Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-5c87853df28so5484082a12.3 for ; Mon, 30 Sep 2024 16:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1727739247; x=1728344047; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=prIeTSYiKIvJS+EE6ej8fL51jvYwgStC5lRUrm72WxQ=; b=UpOrmM83xcRL5KxAPMQGOkDdJp41N7/MypYUz4S9o5K4QiRKOfXnzI8lVV0aL7RCSn mJAXHHfiOOOdU0BJk0OoaIwKAHOdHuLfJP+cTUhHHPnLjYyj6Au8BTfovje3oRhf1IC/ 9iaab4l6GfuvKkd/EOtH/lJX5ZqT+ZrTO5wgAC/ImxBJ445LsW+iJ5v+2Vle4pd9jRqF GgXwKrqiewGjTHGtZU+AXZ86SGbaDEF1LJ+reqWkuja/HYP6M2KRzmQ6sw9VdkYdEyLT vivK8FyGWFR/C29rwdzJUQR5yy7xFfUQCXKSuTPQkG+YC0G/TXYpTNBtHcjFx08m9lSR PGvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727739247; x=1728344047; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=prIeTSYiKIvJS+EE6ej8fL51jvYwgStC5lRUrm72WxQ=; b=bOn6jk4m/4HtlLLuyJjqlj1skjfmyiMCR2U4cClanl5oTeTmsqabpwbA6FOPRknzKQ iZLRboSR7xFjzMAsPRZWzfn9hk+6OQ/3rfWLeHMFqcnp8FGE3KxXAyMPmKeyJFKKmKFP gdLB9RGDnHzxbs9lhiy4ZqOf15BEr7zd36TwC4vmMMf+hHWEw4TFUlr0TxMwuEZjVg13 6lubDokbBtThH7LI2sMpNsvMlxhCrTJI5fZB7+cK880h2bpwaCE/hPXA8u07fJxgJJjE WLpVZ2+bqYThA3heehlQ2iJVxk+G0c+avecoKvCNkqX71kEyxr0+sjbf6seynWSFoBpV xSPQ== X-Forwarded-Encrypted: i=1; AJvYcCW3tDAMMb2HEBI8RmTQHxuFPtYDEv9y5QSZfqUqJ0nbCln+88TymLuIyztJlpNpvZOGF9FPq+a+DA==@kvack.org X-Gm-Message-State: AOJu0YxHf9TsDtxFvNM5usLDacluIJMA39Gzrago+pxeKK3DU7H9ObiO TpD0waFR/mpNpPryywh03bH7pUpV14cTDcOJuPDRQOBOe6PoMgFu9KsWdAqcT2au48DBtX1YP/F BlzsnfTW7WWjw4N514slfvxX1+rBps0mbQl/z X-Google-Smtp-Source: AGHT+IFTIv/XSXdKGQFoGAvZXtPLinOK3hqnuS5gesnUD4L+bmERC/C7ox4l+yT6DV4FgbShZunzJz7g2V91sJWft0o= X-Received: by 2002:a17:907:8687:b0:a8d:3998:2d2 with SMTP id a640c23a62f3a-a93c4aa6b1amr1523866966b.58.1727739246520; Mon, 30 Sep 2024 16:34:06 -0700 (PDT) MIME-Version: 1.0 References: <20240930221221.6981-1-kanchana.p.sridhar@intel.com> <20240930221221.6981-7-kanchana.p.sridhar@intel.com> In-Reply-To: From: Yosry Ahmed Date: Mon, 30 Sep 2024 16:33:29 -0700 Message-ID: Subject: Re: [PATCH v9 6/7] mm: zswap: Support large folios in zswap_store(). To: Nhat Pham Cc: Kanchana P Sridhar , linux-kernel@vger.kernel.org, linux-mm@kvack.org, hannes@cmpxchg.org, chengming.zhou@linux.dev, usamaarif642@gmail.com, shakeel.butt@linux.dev, ryan.roberts@arm.com, ying.huang@intel.com, 21cnbao@gmail.com, akpm@linux-foundation.org, willy@infradead.org, nanhai.zou@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: fxodax78zn1jw8thxxub113sns55xqc7 X-Rspamd-Queue-Id: 3BC53A0008 X-Rspamd-Server: rspam11 X-HE-Tag: 1727739247-475468 X-HE-Meta: U2FsdGVkX1/cSLF39dW2LNMHlnvVGjeXwZEsuAxWvzLtzUm+qZuMky2y3e9SRVtyk9uiqBWLywD1wj6Gvhyd64U7/lvRq09QHE9AtNI67bEt5cTbED7n1s3Row4T9WlWLdV4kg/BiznzOBgsiFTdJwXhwJ76toQ13H3MSMXoPV1Kt//uz6qbM68FiQ9s257EeSSFLpROY/FQ5eIq8nAgS83iaiSgiPDIgwQu6uyY7O1fQsXFoPP04nDVI15EUJkTwtjWC3WIGbteXwraxTqBnZMnpgLrUlhGFoMYcFqbzTmG7alWuNsgs06R8tRg56PSgHoN8tb/kd796zE3fhZJzYJOeOoQaj5EFfRDwucqfCXyTBILFtm4RBGxP5FF+oPBOUu3Hb3n9ajZi+PJlsoEthu/pC0oiQ4f05NfFCLg8WKJOYsPFG8DQ8TnZbmOmbpUIHx6WmMDVjzw1Aa11Thm8Ijul5Hrr7Kw0S+GwJYkp1sCp0IQmiu3YaVAQ0vU1iyIyKU6X9eLNtMeCwTCAO3kFyyLQCv7ef5y3ekAhGwuGf5KEVToW9eRTHiYhJmb9sNFK66yxCcOfdyhWGzugZ4fv8WdEWy6BFfTZpHtT+1fDQI0DtzrzHuO2xnGzv9uJg3iIICrlNuR1hZbj3SpHm/SrWnqKJEjoFvchWWNv6m8pdSKzTEllKSukzrPpTwrpgheEqOG+kIm+7ERYOvwW//MCbwRWu+Kr59OpmgaxaAvhNv0jt9k0nd1LtFVA8Q+nN/q9jmbwxmheV2q4SlX3bDJskQvHoUAVzRuSQV/SBMi3HRVqPRjABO8N8AoUASBud4XmaRqVsx8kzOUwTaZnJdoj/3VhqfcHqaYz/LqajLIWzgaBfdBk8VYqu+qBS9b+SlBHai5UNwo+ONO2goXikFtyhmgfQbOf0kFQ9X/A9eGSm6TU1dvN+87xvYQ4hqZWQu+0n9Rd2fZxlimQgw8h4/ Rdh3E03s mFPDPY4ufkWYaZTWlJGt7Lez4fshfTl22r/NbyQcjUqY+J3ga1+aP+2RO4Csgb3Od+dlpYtAFcK6+YNOR7czGhRcQLLVkBtMGB62rF1Xyrnhjf4zJB4I/5Ycqc2JR8OTOL4Kkg8mKzx/6AoVJBjA5C6OjsYTkKkKgmPLBsps46BF0pXyYYJ26sOvFKZEkZN2VvLyBm378gt4h9v6dFavRIRo/duGPIz6Y2OQnRnZlyMeupL2IWcQK8FUuSMSnb4gqwtJssRUnctt1vwLc/WvrPD6QlxzQf15Eh2a7hzaecmc5x0VCIywajt66j865tL3kFxLUFWQdOrRRX0H5UiUSwCj3Tg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001260, 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 Mon, Sep 30, 2024 at 4:29=E2=80=AFPM Nhat Pham wrote= : > > On Mon, Sep 30, 2024 at 4:20=E2=80=AFPM Yosry Ahmed wrote: > > > > On Mon, Sep 30, 2024 at 4:11=E2=80=AFPM Nhat Pham w= rote: > > > > I suggested this in a previous version, and Kanchana faced some > > complexities implementing it: > > https://lore.kernel.org/lkml/SJ0PR11MB56785027ED6FCF673A84CEE6C96A2@SJ0= PR11MB5678.namprd11.prod.outlook.com/ > > Sorry, I missed that conversation. > > > > > Basically, if we batch get the refs after the store I think it's not > > safe, because once an entry is published to writeback it can be > > written back and freed, and a ref that we never acquired would be > > dropped. > > Hmmm. I don't think writeback could touch any individual subpage just yet= , no? > > Before doing any work, zswap writeback would attempt to add the > subpage to the swap cache (via __read_swap_cache_async()). However, > all subpage will have already been added to swap cache, and point to > the (large) folio. So zswap_writeback_entry() should short circuit > here (the if (!page_allocated) case). If it's safe to take the refs after all calls to zswap_store_page() are successful, then yeah that should be possible, for both the pool and objcg. I didn't look closely though. Just to clarify, you mean grab one ref first, then do the compressions, then grab the remaining refs, right? The other thing I would be worried about is code clarity, not sure if it would be confusing to initialize the entries in zswap_store_page(), then grab the refs later in zswap_store(). > > > > > Getting refs before the store would work, but then if the store fails > > at an arbitrary page, we need to only drop refs on the pool for pages > > that were not added to the tree, as the cleanup loop with > > zswap_entry_free() at the end of zswap_store() will drop the ref for > > those that were added to the tree. > > > > We agreed to (potentially) do the batching for refcounts as a followup. > > But yeah no biggie. Not a dealbreaker for me tbh. I thought it was a > quick change (hence the fixlet suggestion), but if not then let's do > it as a follow-up. I don't feel strongly either way.