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 B4BFFCF318A for ; Tue, 1 Oct 2024 23:39:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 31CF8440166; Tue, 1 Oct 2024 19:39:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A66468002B; Tue, 1 Oct 2024 19:39:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F6AD440166; Tue, 1 Oct 2024 19:39:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id DE74368002B for ; Tue, 1 Oct 2024 19:39:30 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 90092140DA7 for ; Tue, 1 Oct 2024 23:39:30 +0000 (UTC) X-FDA: 82626652500.11.6442E67 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by imf11.hostedemail.com (Postfix) with ESMTP id B22D740013 for ; Tue, 1 Oct 2024 23:39:28 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3vjmr5fG; spf=pass (imf11.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.44 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=1727825841; 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=QC9leAnVpIQ+0a8Li0BvdERjab0Ohtpna3h2EZ7AVV8=; b=ofeTLKMqs9W/FL+fU3wkb7o925dwJLTjMMAOD7w5L/oDzbeyYkA7RFGoqDliuT9Pqnuq1L o/IrMQ2UnWx2/jw9qNji+GCA/yfX5hhRxjWgf2tNTjOAbkHQ0D3D94OVU5E6M85zLemFEz oc8qJKGBh9q6P9Wo3kQHYdNnqD7t8+E= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727825841; a=rsa-sha256; cv=none; b=KzI/HbI2BHWxTnENgEWsX5AEZigef4avczpStIAtLzC8XUCNob0dFf9uRgpDqiOXp/0weR jGWxOrUPzeT2qPAdv1yhAul2hwZAB+/DLW9B9XKSYvU8R0hu8ZOLphhrXKjP+ghFKPXcUJ S9xnASdZhw+PbCW9Rc43EKKKuyxLA4M= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3vjmr5fG; spf=pass (imf11.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.44 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-a8d0d82e76aso981139866b.3 for ; Tue, 01 Oct 2024 16:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1727825967; x=1728430767; 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=QC9leAnVpIQ+0a8Li0BvdERjab0Ohtpna3h2EZ7AVV8=; b=3vjmr5fG6GFcXr57DEt6o/ZvuK8YOeI75ivByH9joP7z8JfQ45jqRvghub2uFVJHJA 9vXpmf8goleyxrNi1Guy8+wqAOGsjdKUQOoOn6XezY/hSBkAast6ubJiRymAO0GFLRjU qYB+s86LhFS5h1iqQmyNuOZjlv6zNa5hYd2Ai8XfvF3EfO+a+H8bfIrSm8szK8kiGP8M 9MXfP/eELTMdxmiNqE8ZEYiVJG6ViXm//uSd9Um/ZgnGmwVHVHCF/aQLbgdNavRIDxUn aclycNCOC8xmGb/5kJqf1EfBm5dVlrzEj6hl10+uCAhnKU2d399Uq/zLL8a878xrBkdy VsPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727825967; x=1728430767; 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=QC9leAnVpIQ+0a8Li0BvdERjab0Ohtpna3h2EZ7AVV8=; b=fx8KHAOn58ZvIQFD+TpMDkEfK/4NcbCyh1lj/3CyLslbg7WmebuyU0U72u4E9ZUVo1 t7alFF/QOzVCX5agV9H4SdbQCgTnFD1Hm9Y5fg61DbDJfuS/SrWkvuz+OEnj6Q9ZXhxE jeOuDIXr0W2Mh4GFcKqMqqzhqMj9sZYBG7w8gImElItw9rEaxEtm+UNC/Gxpv0z/7bCM pDCwQKp0dEh4JjklbfaPJnBmjxXxingiTEj0i6a79D0VeDXODuzkN7U5SDzlHPHWFSx2 fLGwFc2rMhKR9GVWocZAvKendTVsA2jMEDuquKis5chv2BDk8MsRo9npPF5/XNMQEYHZ Rdhw== X-Forwarded-Encrypted: i=1; AJvYcCUzW3GM5PpRARE8yoFoJLoZvQesjpjcVPJm+hhjObhBFybsauLGq5vyJkhCLpTda9SpjTFS0AgQMg==@kvack.org X-Gm-Message-State: AOJu0Yz0OMqFzck7oEfhH3zdIfcYGra6lmnMGYW7VnKPTfrn3yYVxbRL as/BUF2/Ekhz7o9q1u6lZO7GgvHQnd/ZOayqoh/kD4qwtA5rhpLn5VGAGM5NGBZJxTR4pwZd8cU JUHGo6aU+yr8a+3D6nsxUrFwZPCJ77KLuv0pb X-Google-Smtp-Source: AGHT+IHsJrzJEvc35ZFGz7GYfG/WCB2Oh7Vz69PPyMNzybiu7Fy/SAfkJMOZoCJ1y9gJxgTFmnRAuPxDsAfr+r4o8Kk= X-Received: by 2002:a17:907:7e88:b0:a86:b64e:bc4d with SMTP id a640c23a62f3a-a98f8371b0amr97137266b.44.1727825966694; Tue, 01 Oct 2024 16:39:26 -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: Tue, 1 Oct 2024 16:38:49 -0700 Message-ID: Subject: Re: [PATCH v9 6/7] mm: zswap: Support large folios in zswap_store(). To: "Sridhar, Kanchana P" Cc: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "hannes@cmpxchg.org" , "nphamcs@gmail.com" , "chengming.zhou@linux.dev" , "usamaarif642@gmail.com" , "shakeel.butt@linux.dev" , "ryan.roberts@arm.com" , "Huang, Ying" , "21cnbao@gmail.com" <21cnbao@gmail.com>, "akpm@linux-foundation.org" , "willy@infradead.org" , "Zou, Nanhai" , "Feghali, Wajdi K" , "Gopal, Vinodh" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B22D740013 X-Stat-Signature: kncrd1nbcgi6fx8qft8q3hkprzgxdzu8 X-HE-Tag: 1727825968-527057 X-HE-Meta: U2FsdGVkX1/YVxFAXTGCqAXERzG+Dm8RsZfDtj5evwvzYad5xoQVq/v02uzLUg/BU8o8PBlGYjOfy0fC8GFfNegVKAIv/BZ4v9U4nZYc+cXqn5qJTsxF3cU0+D+fUeWqbeGp4gYYkTuHdUouqIXs83pqAyV3HEdJ+WUGoW/hDXKq+AkmgPLc6zBwim6R6kOj+sTFm/FC8k4AgaodcBDTzP4kV7SDZFazdqdYYCEzVmV5LCUwze8/SRkXX55lNfatJzY2WnMG/yk4u90F4dcg7gTRFJbWLsAcTC6mM1OjSdKUr0U7aTC3BXpF5ISpAFkVUEpk4pUiKZw8iR3+O3mAZlGy8Q90EzwotUr0VIFJixpLuBZG4I0Y5470aNOvJ/sZEGVdF1KtVkZJtoLTM2aLOz8OPFwvIMF0GvIIhJD6poGJMAQgWfTtXNdHFzzch1ZT5IH+/iIklbqZl3GDuE06hGjMFF28JA9JAewTQMX7Xvp3Sg4fnT4vQ/loijkJSBe6MUCsc1fXBB/2mrfreTbBlHxb3T8BbzJ650LUWZlLjey1WroAeC2BkNMlojbc+XF4imA9dgF7KhCCY7Dq6y+fc9NENEYATG46pZJ6ntXOGA61MyXPv6u4CqoxFpKrwbi3aNHHN4lB3QxqpTLL6mvOML3F2sHF1ceJoF9sUI13Rfq/Af48ru59yVJoBumxaAD060Du/YmAgnitf/lKlcNT8hY4Jl0vNkfQ9a9ZRsuNphjFE2Q8nUfc7cYxqICaMBmYMIR3PZmkmhwTvLSJerjD/m/zL0q6Ow8RmAygro87xvVKdfjaTibzMqiM8ZEH8LtIiw5SIm8m+yHyGqfdEwgI3O5SfXuBZ8bFYn4P1WcKPNIR9OW07/HmuTDNLPlSUOFzZiUYjJ3B6FEMKU4B5hUhJIEfat4I4IHK9EmBaZ9gMZFIaoJxwjtGJPHNY7gvkXF6WoFuq0h/Sk3T+NJaAho JH89U81b nYWqx6bV3vA48eewSQn2kTjoHfL9irgXPCd7EBzBGMtqXRzzcvwulqfhpYWmC/YgyZfwc7zIgYHUnzyCbqcuHAJx7yh2ZG+wRGqb2zRApgNeTSorhu9lUFPCg8s40rHKBEH+iQ/4qqb/QD44gc/1HxU0hB9ixHEmiQJIjTzJ46nfsp/EH2uv4JA4y9EvAilq7qxQ/7cq2vPR8V4GasCLOVVr/GVumPINXmFIiZ+GYLbHFaHGV5te4nIMSCDjO0BRBlQsm81i+Ckym5CqfdWu1tfmzmw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.007784, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: [..] > > > > > > > > store_failed: > > > > > > > > zpool_free(entry->pool->zpool, entry->handle); > > > > > > > > -put_pool: > > > > > > > > - zswap_pool_put(entry->pool); > > > > > > > > -freepage: > > > > > > > > +put_pool_objcg: > > > > > > > > + zswap_pool_put(pool); > > > > > > > > + obj_cgroup_put(objcg); > > > > > > > > > > > > > > I think if we reorder the function we can drop these calls, m= ake the > > > > > > > comments positioned a bit better, and centralize the entry > > > > > > > initializations. I am also not a fan of passing a semi-initia= lized > > > > > > > entry to zswap_compress() to get the pool pointer. > > > > > > > > > > > > > > Does the following diff improve things or did I miss somethin= g? > > > > > > > > > > > > We shouldn=E2=80=99t be adding the entry to the xarray before i= nitializing its > > pool > > > > > > and objcg, right? Please let me know if I am misunderstanding w= hat > > > you're > > > > > > proposing in the diff. > > > > > > > > > > It should be safe. We already initialize entry->lru after we inse= rt > > > > > the entry in the tree. See the comment above the call to > > > > > zswap_lru_add(). Basically we are protected against concurrent > > > > > stores/loads through the folio lock, and are protected against > > > > > writeback because the entry is not on the LRU yet. > > > > > > > > Thanks for the clarification, Yosry. Since this is a change in the = entry > > > > initialization wrt the mainline, is it Ok if this is done in a foll= ow-up patch? > > > > > > Sure. We can discuss it separately. Do you want me to send a patch or > > > do you intend to? > > > > Thanks Yosry! I will send the patch separately. > > Hi Yosry, > > I am preparing the follow-up patch so I can submit it once this patch-ser= ies is > merged to mm-unstable (since these changes have dependencies on my > existing patch). > > Is my understanding correct that the folio lock also protects against swa= poff > happening in between addition of the entry to the xarray and initializing= its > members, which will need to be valid for > swapoff --> ... -> free_swap_slot() --> zswap_invalidate() ? Would apprec= iate > it if you can confirm. Yes, the folio lock should protect against swapoff, as the folio must be in the swapcache. For shmem, try_to_unuse() (called by swapoff()) will end up calling shmem_swapin_folio(), which will lookup the folio in the swapcache, find it, then lock it before proceeding to delete it from the swap cache and ultimately freeing the swap entry. For anonymous memory, try_to_unuse() will call unuse_mm() -> .. -> unuse_pte_range(), which will also lookup the folio and lock it before deleting it from the swap cache and freeing the entry. try_to_unuse() will also loop over any remaining swapcache entries, lock the folios and then try to free the swap entry.