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 63A4AC47258 for ; Fri, 26 Jan 2024 00:10:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ED0026B0074; Thu, 25 Jan 2024 19:10:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E58E26B007E; Thu, 25 Jan 2024 19:10:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD20F6B0080; Thu, 25 Jan 2024 19:10:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id B67846B0074 for ; Thu, 25 Jan 2024 19:10:21 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 7F62280EB7 for ; Fri, 26 Jan 2024 00:10:21 +0000 (UTC) X-FDA: 81719530242.08.A40CB2F Received: from mail-oo1-f45.google.com (mail-oo1-f45.google.com [209.85.161.45]) by imf16.hostedemail.com (Postfix) with ESMTP id 8908B180029 for ; Fri, 26 Jan 2024 00:10:19 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=j+n8S5EZ; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf16.hostedemail.com: domain of zhouchengming@bytedance.com designates 209.85.161.45 as permitted sender) smtp.mailfrom=zhouchengming@bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706227819; 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=mepq/n4r76tjXgMd8bs61Q70KlbyLsCs5QleHM4o5pw=; b=HttqT35FERowDuasVTtXUbCfRRRw0QfVV4KH7bWPzKzoBFI1W8L8QbNpZ9TqQ9Kpbyp3Ih VU+WHdm5CHxUcb4bTIqBWFNJUawsEmfSi28rFd+TErMOnfEWSD9myCP1X3WB4ktaNBR6ns LUxdz7Q7Rdg5FAkHu2r8OAcx6uoSdvE= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=j+n8S5EZ; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf16.hostedemail.com: domain of zhouchengming@bytedance.com designates 209.85.161.45 as permitted sender) smtp.mailfrom=zhouchengming@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706227819; a=rsa-sha256; cv=none; b=npADa8oTeuimj2igZRw/Eg5EkBgB0Ma1zS/CkEafVQN4TuFHgzgTVFkb+9JcZ+s9lecpnn LVsIH5vtFF2jFB7GIMOmrv4z38uwvpSt4aiJI4UcL1veYLM9P2SNsAY3XBwcY0BWfXHpqU B2kyuLEtw5i1nST4ycvYmVEwyxmHpCU= Received: by mail-oo1-f45.google.com with SMTP id 006d021491bc7-595aa5b1fe0so4452591eaf.2 for ; Thu, 25 Jan 2024 16:10:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1706227818; x=1706832618; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=mepq/n4r76tjXgMd8bs61Q70KlbyLsCs5QleHM4o5pw=; b=j+n8S5EZKeExJC2Tk0G+9slEfsFZy0EalTAXpNuJZmOf88GW+Rt+yH+qYcgkFF+/oY v+9miDfg3AzwcEpZV8swVBMgXFP1gdbA3vPe4Nbw0aRgTfhu46sikYlKI6j68IOqFjMb wS2KeSDmiaN1xqPS0PQZBchKrZMRCR/hWORtiGmUXFltSdSVPMlCOKm1Ag0ye5rhxE4e Gxg+HpWsNa1VPIpszRoDBzuKNNJXhOgDLzdvr6AKIWtB8lZkzR35qsHpbfdGtgpm96o4 qLuMX9qfVzRvMPpG7U9v+96JwP3LOF+4761PAF/p36KVhacgCUdvXEuoPHY1ipXSULaQ zbdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706227818; x=1706832618; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mepq/n4r76tjXgMd8bs61Q70KlbyLsCs5QleHM4o5pw=; b=ewZmsoJR4fWM62UDY6mIwJEmRaZchGs/8/yaJyCmc4DRJM2r7gweo2tJbZe+neUSGY DAh6106U80sXRStEZsjGgkkIRaLTXww5TN+p81Z1oZYcm+zQ/Zwm5cedAUzon68oCrc2 SAch/LaQf90h+1sX3wDvOv/EZM+HLjvuv7FARZJqoXscwbH0S4JcK5CsNKvSJEPr325S IKOQEQJnMKS8w2bBaY0QKLeHxv7TIKK0Se5FtaXu1TtW+8EZ+B3bgK9H265qWYTz49bw j9OtA4yRo9zODKCCXa2NMYe/WoYvbxt8mL3KOAoHv3YHuvOVXnYVkwoLy7Qfld2mraps pqqg== X-Gm-Message-State: AOJu0YzeFi63FEA1stfA3w0OzK2tLqbdxeKosdteSNGqiCFSOAbI90yV Nb4rEAWHKDHNLyc24axWwODqtBq2k/LNQzZqDQILdOSq3EBKdNShvXZcUlE0K48= X-Google-Smtp-Source: AGHT+IEx73KHQAhkebWlIVIn3JcUudSFf9fDP998OFKdpnla84QeM2u2dcu55JYb8yCnAvAsuooCBg== X-Received: by 2002:a05:6358:ee88:b0:175:4d29:ac23 with SMTP id il8-20020a056358ee8800b001754d29ac23mr701341rwb.26.1706227818446; Thu, 25 Jan 2024 16:10:18 -0800 (PST) Received: from [10.254.148.65] ([139.177.225.246]) by smtp.gmail.com with ESMTPSA id b7-20020aa78ec7000000b006dde305b92csm93398pfr.118.2024.01.25.16.10.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jan 2024 16:10:18 -0800 (PST) Message-ID: <081a9c21-a1d1-4ca2-a58f-e6748ccb429c@bytedance.com> Date: Fri, 26 Jan 2024 08:10:13 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] mm: zswap: remove unnecessary tree cleanups in zswap_swapoff() Content-Language: en-US To: Yosry Ahmed Cc: Johannes Weiner , Andrew Morton , Nhat Pham , Chris Li , Huang Ying , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20240120024007.2850671-1-yosryahmed@google.com> <20240120024007.2850671-3-yosryahmed@google.com> <20240122201906.GA1567330@cmpxchg.org> <20240123153851.GA1745986@cmpxchg.org> <20240123201234.GC1745986@cmpxchg.org> From: Chengming Zhou In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 8908B180029 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 8wpmrud3y8n66pz3u7h4kfmftu5wffpd X-HE-Tag: 1706227819-91047 X-HE-Meta: U2FsdGVkX1+6cCUdln0pP0P3c/GeYRwJXJ3Svp9+CCQilQqUzKud0lxPF6fthmR+HXXlKTamJABxSN0f92/rkFGiqy4Qyjy8rY0emLox2CCTGVHyHf8KMrfzUJJbUfZePxTWpfV0a4wPEVGiSC0pEO601bnJIIC1k7bAsJQGD4ghOUGtv8mbjTcUDSZXmQFjhwX8SqhTG8jU+O0WsWR5uTjGuB0x6w/RVYA93v+jjVMMiFvpakmI5r1XZCh0WP0x0V9EDzKTiFAD2Rv+PUQ4Ii5CFXJKwU5FBraQQ3m2PCozp0SG8C4f+0EIfBkm39SgQ9idCVwuAcEGNDfOvdlaSqFHT9LRBXnV6hM9iO+XHb9D2lgHVnXXoctrTLafH/NBN/cSxhWBfg5UXRIaA+uPA5M0A4vLlS6tevD9jNoZq3E3HHFjVOozKpHbMsS8e8E1Uk9lOQYwQhMsRD2kEWW+90saieDk70uWGpLBGVLIYRkJY4+bOvHAjvN/ypRVP92lDZj0fQGLELUBWn7yUJspCHb5X0HzYm8TOug1IbaV+ZMfC7OWDzFKLVHKpKm6TATj833wALnFBFQw5YF7cYIGcAnzMszIGSX7sJ+fFL9esSbamBd8DtpcRNUWO5LBXu9Iv3noGA9/3X6yVZhKlNzfd5kHCRDrq9NdF8PS8zPb3apkE12TAWOfBMk2hco0ERKBHMLMLGy9zGT66wzomCCNQLl3WZGeFuldTEOnuwEK3508O3+IW21OBs1xBBp9lC5Ixuyo+l2YIOHJlfo6/1fHsM/9/OEusYEESon0MEgd0mIOg1LZUiznaRIAifPXtpUAi95IYXTssbphgCFN7skAllNO9uWfdiU+cX9COEyJPQCONP+d5QMIqtd9Nr4X/e3xzHWk3TyHyQ3PS2Z64Nl3Oh5TsPmbFXVe5hciFeKds35N4S6ZJhs0LB4q1ngsUQ4nNrRliCk1N2oSmcNjhl5 B/JHhmCa BOYp9MuFZJf6u2RqsVDInO8FUpnENbuyQUjaHDffofz0EKjAr8X7CK2C/vgC+ilhtpiiHTzXo7Pg154jH5Hs4OLndVqjSuyGxeelFsq30TkRrCzv4aSfcGjdaQceyHfqVKCP0irG9iyy7Wg2B9DvjQbkRFkH91MFHDC47k0nsJjbhe6hgCbOcbfrc1t8rzwManeBVjE3DBl27s/DuK0yVFTdPvyR/ccsI7xlnCKVAnV+8BFvZc+83cNIQef2tZzXXIUZ/ciQfNJFHTKhyvf6eQTrb8Tut3LjzfRqMEbXV3IVPJL2WDw/c3R77JOup1mnKQhwiJg9WaCohd9EBHKbaDvsrsCzXDDK9m9o4W621RelxSQKDmUbA2YV+ZgdeYHLsHK79WOsBzggA/voswhN+7KA5AuYzEcAQNIbUh2k1riKwwqv3vtWqcqwQN3kkjuBjFLGDxxkq4pwNDnui+k6pjhmVTaPUbZZOwLI8zelkVt6g0I4yVWCOwHqKcES3iNwNHJLk 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: List-Subscribe: List-Unsubscribe: On 2024/1/26 08:05, Yosry Ahmed wrote: > On Thu, Jan 25, 2024 at 4:03 PM Chengming Zhou > wrote: >> >> On 2024/1/25 15:53, Yosry Ahmed wrote: >>>> Hello, >>>> >>>> I also thought about this problem for some time, maybe something like below >>>> can be changed to fix it? It's likely I missed something, just some thoughts. >>>> >>>> IMHO, the problem is caused by the different way in which we use zswap entry >>>> in the writeback, that should be much like zswap_load(). >>>> >>>> The zswap_load() comes in with the folio locked in swap cache, so it has >>>> stable zswap tree to search and lock... But in writeback case, we don't, >>>> shrink_memcg_cb() comes in with only a zswap entry with lru list lock held, >>>> then release lru lock to get tree lock, which maybe freed already. >>>> >>>> So we should change here, we read swpentry from entry with lru list lock held, >>>> then release lru lock, to try to lock corresponding folio in swap cache, >>>> if we success, the following things is much the same like zswap_load(). >>>> We can get tree lock, to recheck the invalidate race, if no race happened, >>>> we can make sure the entry is still right and get refcount of it, then >>>> release the tree lock. >>> >>> Hmm I think you may be onto something here. Moving the swap cache >>> allocation ahead before referencing the tree should give us the same >>> guarantees as zswap_load() indeed. We can also consolidate the >>> invalidate race checks (right now we have one in shrink_memcg_cb() and >>> another one inside zswap_writeback_entry()). >>> >>> We will have to be careful about the error handling path to make sure >>> we delete the folio from the swap cache only after we know the tree >>> won't be referenced anymore. Anyway, I think this can work. >>> >>> On a separate note, I think there is a bug in zswap_writeback_entry() >>> when we delete a folio from the swap cache. I think we are missing a >>> folio_unlock() there. >>> >> >> Hi, want to know if you are preparing the fix patch, I would just wait to >> review if you are. Or I can work on it if you are busy with other thing. > > If you're talking about implementing your solution, I was assuming you > were going to send a patch out (and hoping others would chime in in > case I missed something). Ok, I will prepare a patch to send out for further discussion. > > I can take a stab at implementing it if you prefer that, just let me know.