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 5D89DE77188 for ; Wed, 8 Jan 2025 15:37:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E94656B0083; Wed, 8 Jan 2025 10:37:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E44DD6B0085; Wed, 8 Jan 2025 10:37:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBE2E6B0088; Wed, 8 Jan 2025 10:37:18 -0500 (EST) 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 AB9C56B0083 for ; Wed, 8 Jan 2025 10:37:18 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 32CF4161205 for ; Wed, 8 Jan 2025 15:37:18 +0000 (UTC) X-FDA: 82984688556.27.5B3C232 Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) by imf08.hostedemail.com (Postfix) with ESMTP id 43E4B160058 for ; Wed, 8 Jan 2025 15:37:10 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kAMBJL3R; spf=pass (imf08.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.43 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736350630; 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=y8t0nUswEKUQa5FIqCjmM3v3R31MQI4BLiaMOGwNrEM=; b=QZMEPY7C/woNc0a/Fmrj0WrxyyXwC8HWkz5RRPE840/FSEPokd10ufxNHMsoT/oq0sJC0Q F8mYqms98wovVvbsPGA98NnJRRGi/+wgFAJoZd22AXB/xuoUmaOQ+xp3605/5IgEcBVFAb jvAr41lxmHdvkCMQrdujJsq1Sb2RVqU= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kAMBJL3R; spf=pass (imf08.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.43 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736350630; a=rsa-sha256; cv=none; b=SM+FGuOVLeSKiB3jUp3PaPUncuYvPG8xFk29JH9Biz3NSN0ob8HccuCMydfppsbTw1h50L ih04KzfWP6SSbUdXOT1GUFYsKXVvEp8o1fR5vs/9zB5r7ofIgKYifLCv2XC47RKYXH0Pk4 Jgv/EA26MzM2EfIVQps7DOghgIRspp8= Received: by mail-qv1-f43.google.com with SMTP id 6a1803df08f44-6d8e773ad77so130114386d6.2 for ; Wed, 08 Jan 2025 07:37:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736350629; x=1736955429; 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=y8t0nUswEKUQa5FIqCjmM3v3R31MQI4BLiaMOGwNrEM=; b=kAMBJL3Rh1D+JmYP8VniMeFJ4Vr46sDjLA8C0uWKbJPYG5QopUVVzRfnDX9tYJwHcF qyg14+N0xqiEG9mYsLajOiZEc3/w60yH1WqQ2UiTKUf4rMKJs8tRiSblYjxCI1vDrUe/ luoJjZjkmOmxGSK89M7Vpq7uPVmllzlvHcp7zx0najNtMxqdozBvQsx1ayiwECilERd+ XeYJYh5JI5x979OUojeoX9RDkKW83JfvxkT4Mh6bGq3/a23jJdMLx9PEBF/CNicosQCE Al1Z90fdi4CaJnNqS2WA0fZZKkjyAeB2tHOi+QyZwofv8NoPm/m5X/8PgMr6Gi4hbqJg Ov6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736350629; x=1736955429; 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=y8t0nUswEKUQa5FIqCjmM3v3R31MQI4BLiaMOGwNrEM=; b=KStEJrtRudR8gcgDzYRG+YeHApJ29wok+qxxgCaw75gn9iOfY+8zE6VANmKmFlbmAL bMojw39tCNxVIjdVbxU1FGHuZX+H59LUPMjQZB8F9PwhjGRe2q9tydqotd8vN0NfGl8B uzTFs/660AYQAp8RDFc3HuYbO+VONjGA9ZyzqnQ45hMOu30bJ9OdLLqTA9RQYqHTPXZz oq5Tofl86HO7iI7SHBhi8W03Lyk0P4AMWWMGFAoTz4ajfB6TCAdeCKqfS0wUx1a/k0r7 Vo2veiHz/uWKvwav8rH8Q9IvySnWC+Og5BiMVdvakBoEbBY9Wsmwq9d77X3osmHV/35E tX1A== X-Forwarded-Encrypted: i=1; AJvYcCVaDh/tDwy4GpgdN1vkNTtwNjIH+RpPpY+0v9bgp9bwUCd8RKSoLl1gTz2Q5A+6gAG/UT5v0Tiw/Q==@kvack.org X-Gm-Message-State: AOJu0YxYwMv92YusPIylUjeQmCXP5a3XPYHQAHsd4Ma0pz/AokxxheLq J5yrbvBnJ92V5dd9KBpipdqSuG2vAUP2fMj7Na2EmaBX1sT/bQpcGcsMQ87LhQmglekSKGZB/r9 P3Zh3xO74SbiOhvNPkl3tDn+16uY= X-Gm-Gg: ASbGnctQcOH7V9i06E0ytuVW2f9VED38yNLfS0mONAHg+js8zCr4X41+aeXCpPtwZwE tHpr8OF4nqJ1EfMGUTdcTRwEd4J+ZGSLPJfLvE7U= X-Google-Smtp-Source: AGHT+IF+dzISC56w3I8H6HkJER+DxC3dM2D82Yc0qvMHFTLPWwx2X7P2Iqd0AEfswyAbd/ImrNwE1sYIGQ80c1oS30k= X-Received: by 2002:a05:6214:4015:b0:6d8:8f14:2f5c with SMTP id 6a1803df08f44-6df9b227e98mr59691006d6.23.1736350629410; Wed, 08 Jan 2025 07:37:09 -0800 (PST) MIME-Version: 1.0 References: <20250107222236.2715883-1-yosryahmed@google.com> <20250107222236.2715883-2-yosryahmed@google.com> <857acdc4-c4b7-44ea-a67d-2df83ca245ed@linux.dev> In-Reply-To: From: Nhat Pham Date: Wed, 8 Jan 2025 22:36:57 +0700 X-Gm-Features: AbW1kvY7ocBpDIRFD87MJScWjoKSRdGbbU3BNMTyiEV1JvS_hR6bngjD5A_O1hA Message-ID: Subject: Re: [PATCH v2 2/2] mm: zswap: disable migration while using per-CPU acomp_ctx To: Yosry Ahmed Cc: Chengming Zhou , Johannes Weiner , Andrew Morton , Vitaly Wool , Barry Song , Sam Sun , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" , "Sridhar, Kanchana P" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 43E4B160058 X-Rspamd-Server: rspam12 X-Stat-Signature: uwn9j3qrshtr56669x3ykre1r695towc X-Rspam-User: X-HE-Tag: 1736350630-240373 X-HE-Meta: U2FsdGVkX1/72mvWPvK0264NWwi7bdOcmVL02sXVsLfGGfM9ttKfLbe6a5fn6/Jb3y34l7hmILlOUI/bVMqGnXNhlzcQtvjhKqbMy0w84L0cVV/rvjpjI2plmy7qXqdMuskUvH1Lu7FHSqYkJxJF8sTnr24jLJtp+zx8qP4LTzY3jT88rN3V7yrGILhQy7h74Eb/bV+z+4ssFkPodKUYFcDO+ny1LHHS95j7DFVUyJpmqyJKJNdpxJ2r5bR9v1o2yRGhHIbV5Xvb8TBGGtxzS9ee9JWPVssAoyVqfY9oqnr29OeZUe525T/kjdxbUXC1cF2YdVg6GHT6aDxcHcjtbTRoeBgowWDJoSXkK77pbuSGVHve6k28DBPupkpJzk2KM2eW6uwFP3N8TeXTyO3QntmPuPL9P4Q6zBD8kRu7BTYvAAAuBW66VOdVFa7VDprNarmGcJ1jVbhNbPxhvCyMLVzgbE05N1TUU2xIkeEcIMhkv7HnzdOOWNbcdKD0KLcQnwVzw1206DIQkEZy7rWBq4LNFQ+4QYWDPZWb5UkMK8AJQa1s/0D6Rg4y1Gkp/YhIG0W5soJYn2CDemknXwOW3T1/pnufmKebfhPc6j+DPS6b6wNB0x9MSGnXbT2Yt7sfYvIKDa+A4YPy3w0FgHIobZQ9RI7Wx9icgEUFfL4hLkjCx4/U4lh+6Zm/+MKYWr3af/4zPzSL95Y9NsDIxoSqlhf7GLYiTqKfCO4NrBH6dPxGRC2DypVJScYNQQVDQAYghs3ADblutMYV66yZAlBwdjOHtA7KD75B7H9oSxNPEJ6eqW+7nup9HJBpjcNW5NNTEsJ2pnF5NjoMx71pXmTAwxmoJEKyHh6RPp76BxOOBM3x30nygVHfvmwjrhJkWBfb5oS2aHtMJTKhxqucNZb2hGYiuprnEEoyI6rChaFmfRvPVdeYXLPM98lT13BmDget8cFV5+EnRFAqN1JRS+q posE+Skr piTQ/f/wfOs03H++BE2F4eA+Cfd042ylDWoe6gjFy/B7Ykzb3GINyEIU+18RbHHfzGScypFchs6lXqDDHgcpZeNPTglyhOJepFe4TLNiYOBanASc9kxVEj8bD00DQAeFf/b6FuDNwmsYbAm4JGscPepKDe6WuETk7nvqFXGSqC+vMm2dnWNF8PhAgadM8C1SL37Xr6JpLy9GMFzQo1Fye/L49E3xqsvnqE6SRutb7yoSQyky4cS+QQy9Q+75426EWN/gR5AO9kphW9xf/dBgAzl6BxMSd66ZxTw3X9JpPjwQgio0/tNpflR26J8YRNOrpLs47DgoQ9UW/48iGi929l4n4NS+iGANvYkWy9jLPx4ZDHYTde4fcVPTdYmrVglXyCwvB0uQnxvFtM1Amfa/OP7A30G3tZ7Ss6HknjApZg4Zeaz4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000308, 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 Wed, Jan 8, 2025 at 12:34=E2=80=AFPM Yosry Ahmed = wrote: > > On Tue, Jan 7, 2025 at 9:00=E2=80=AFPM Chengming Zhou wrote: > Please correct me if I am wrong, but my understanding is that memory > allocated with alloc_percpu() is allocated for each *possible* CPU, > and does not go away when CPUs are offlined. We allocate the per-CPU > crypto_acomp_ctx structs with alloc_percpu() (including the mutex), so > they should not go away with CPU offlining. > > OTOH, we allocate the crypto_acomp_ctx.acompx, crypto_acomp_ctx.req, > and crypto_acomp_ctx.buffer only for online CPUs through the CPU > hotplug notifiers (i.e. zswap_cpu_comp_prepare() and > zswap_cpu_comp_dead()). These are the resources that can go away with > CPU offlining, and what we need to protect about. > > The approach I am taking here is to hold the per-CPU mutex in the CPU > offlining code while we free these resources, and set > crypto_acomp_ctx.req to NULL. In acomp_ctx_get_cpu_locked(), we hold > the mutex of the current CPU, and check if crypto_acomp_ctx.req is > NULL. > > If it is NULL, then the CPU is offlined between raw_cpu_ptr() and > acquiring the mutex, and we retry on the new CPU that we end up on. If > it is not NULL, then we are guaranteed that the resources will not be > freed by CPU offlining until acomp_ctx_put_unlock() is called and the > mutex is unlocked. > Ah you're right, that makes a lot of sense now :)