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 1F6D7E77188 for ; Wed, 8 Jan 2025 05:25:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8A1976B0083; Wed, 8 Jan 2025 00:25:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 852226B0089; Wed, 8 Jan 2025 00:25:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 719616B008A; Wed, 8 Jan 2025 00:25:36 -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 530EA6B0083 for ; Wed, 8 Jan 2025 00:25:36 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id AC3F0140F81 for ; Wed, 8 Jan 2025 05:25:35 +0000 (UTC) X-FDA: 82983147030.12.FF6A32B Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.44]) by imf12.hostedemail.com (Postfix) with ESMTP id CF69B4000B for ; Wed, 8 Jan 2025 05:25:33 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UeQcjuOq; spf=pass (imf12.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.44 as permitted sender) smtp.mailfrom=21cnbao@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=1736313933; 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=YyKIyH7Vxsq0pn4GW9Gt+XVcQVhl4PonXgEBMPAWdKw=; b=bDxECHKeIuANx77IoRbuDSuRwq7f1E0bgy+4o3pd4l/t9b7WlqoXcG1xrUJrmIxGpn073y u/AdFBUzz+aF1HUx/d2WMg1OOmvfl6+/CSml5UYBd6NJ0lIBeWG9Lo8tyMMM+lTDYami5B EUcEq6UYwBABMO6SdKsvm+QGojQzaus= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=UeQcjuOq; spf=pass (imf12.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.44 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736313933; a=rsa-sha256; cv=none; b=iQeaiBhXB0S9obuqYN4ostRXzmcoXGBrdC88GrimnPQ7+Os3wD08cjJ1NG+eCIOgJFccgK O876XuQRGflaNf6eB88GBz2LKgn5Me9Ui2xEM5aSK0oeyGWvxtJQRzNrkfy/DeT+fQUe48 J62kR567Wh3phEiXcbi+YW435fV7Sf8= Received: by mail-vs1-f44.google.com with SMTP id ada2fe7eead31-4affab62589so4368875137.1 for ; Tue, 07 Jan 2025 21:25:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736313933; x=1736918733; 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=YyKIyH7Vxsq0pn4GW9Gt+XVcQVhl4PonXgEBMPAWdKw=; b=UeQcjuOq2PcRthDMTgYVqo+Y7X7fzYootNdmurK8+q6IESYqMEjN1kTToDoaCz4EXM RZxteT9LTFAI7Z4mzDtBC/slnaazsi3afLIREyNzoBF8sb68hsFR5s6PvwpdV0a9bkyt f49OAb0q152ueF9c7fi+96g5Yh5+G6dQbpuWw/5NGf4EUhPZngAy74nBt44Z5S4FRZDv iXu6jfj/stITmvAnfsTvS9WqVhCdW00B7wt+Qp5B5/wMjL+xiVxbb3eGV/aFdp5w7t9f m5dE8ZZ5Kqk8lBnkfu1+GCOE+7u7FKi3KCAgz8dM4eg2E6ioAq0mUF+OjmP4nsIGu6UW 50Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736313933; x=1736918733; 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=YyKIyH7Vxsq0pn4GW9Gt+XVcQVhl4PonXgEBMPAWdKw=; b=b5DA+mL2nhq/AyZvOzWliNDrpwklLWxoXztksN9iaS72R8ir0Aq6pct/98aHWb9y9M U/NyBTWFrvlsOkvQk9d91oTLtOukAv0G6lrIzoGDvczbgLqvkfq1TRwRWMfmGM3cQmdg pkaBGQXa6CzkKbwL7wS1OZGj2LD+B3DjYLFkg8upV96yhXZ8VzhudE2pMyLmt5WnOO0d D9FYozIiZDgZS+D/epU+mYHGyPW9mV7rGPMsGYvZrvnzeffsWmTJbWO2oG07hCqmivpl 4ySJDIwYwuhLxImz5FzyQfQTYQ7nkKGI1sSEZqZ1inpfeybYFjSXvzRwnQlj9UouRBaR 3FLw== X-Forwarded-Encrypted: i=1; AJvYcCUplNwf7Norx5PmoZ0YIctIlNJdN3A+g6CxK+Dh0xzLd43Kv16e0jlQuaN07gHdeLMSeCJIss3l/w==@kvack.org X-Gm-Message-State: AOJu0Yxvzz4eqyNus9xyYHMgaAXWdm0n8b5ABWUW1PnnSa6of9nppgYt yqHNCLYssRvD1xVd2np30Sh7KkLL3lNFdqBhW437Hgkb+t8F13IdidzeYQP/wU7M8TcN5092oLQ ymba5qPsPFAz4lfI93cE6rLckHnU= X-Gm-Gg: ASbGnctiC8J39/eraAXjbsqbJ9C22AFDV+ca3nJKQfL4AwVs+JNtKj5EAYU8TBd0cun oqIez7POAqO1dJa7y5N72PbwJqqWPLm/vGgpkyexA8GGp1I1rhWJRry98F7nMuOzskej6UxY= X-Google-Smtp-Source: AGHT+IHFYfNR2caM2ZTLyDRLVZpt9LDF1Os5D+LOvbtZwZmycjWIfnAzlzv0dNZ6kRNCDi3WLzeWrhhyaHu9wJuPlVk= X-Received: by 2002:a05:6102:3584:b0:4b1:24c0:4272 with SMTP id ada2fe7eead31-4b3d0f96d57mr1052770137.12.1736313932858; Tue, 07 Jan 2025 21:25:32 -0800 (PST) MIME-Version: 1.0 References: <20250107222236.2715883-1-yosryahmed@google.com> <20250107222236.2715883-2-yosryahmed@google.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Wed, 8 Jan 2025 18:25:21 +1300 X-Gm-Features: AbW1kva6CDBPMvSXkPESLCFvzyzH3gmpHo5N45UReVZFtZHqfGgkeQRiULr-yO4 Message-ID: Subject: Re: [PATCH v2 2/2] mm: zswap: disable migration while using per-CPU acomp_ctx To: Nhat Pham Cc: Yosry Ahmed , Johannes Weiner , Andrew Morton , Chengming Zhou , Vitaly Wool , 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: CF69B4000B X-Rspamd-Server: rspam12 X-Stat-Signature: a4kff83agg1ujc9iiwp3ckyreifewbow X-Rspam-User: X-HE-Tag: 1736313933-219331 X-HE-Meta: U2FsdGVkX19BnYMN/FjCKuTJDx4xhIgnKOVATAiCTsPpXHLV67UpedbY+tjTokGQO1R3JY8pv6IAeMrnehfXeuqcLI0/nd2+VxXFO56bIXQajMMUvgpDMOEtxKbFxt6r36H0XXodoESgO97agDqMela4rvfoaMkxylqoHR8j4BuTl7sonrJVNCYvGJUYCqQPc392csj3rim4CXZRShYpyJzHB7zvTYZSCNQXV5GO5tKcV/9LOZTteUg05PHBPq+VtnRVjh3eVZ8F0EQtkoUpti0/Yy/Bv1F63U9c8qa+TjYEAt9aWpxYroYDsJzYXdxsgOg7Lz2ybwj+iztwPv4xTZuyB4DcLtVKLZYIvXd+wSBnA1JfaIVjvUrYKV52nvvS7iqZ8NSW9PhJqJeA3+F3NIBHsawEUBzJ8ie+/imL4v6DSqZt1N00MLeqH5pDkXDtpEhqFIGFoNNUwHOTkd6e+H/gFKqYFxykfhtiU7moDouhTXLqhctWcKhlHsHwn7SOo0SVMFGyzNuJWj5urLfo1YbW5715C74BHRlmI5lJdBJ2z9Im0QurUoYQcxSyOI5zq+I6tYePSFFqAqMnUDFZ6+WLsXD39NaQ6j+609HKEYutgz6zs5O3lthtj9yx/HPeF3cekfgkpfsWJWN+82f7hHdyXg7tEpBuwY3hcY7as1vj+UUlWlu1796UcSgSzygutImON9IAQSiXTr9qQF0DkR+MsiGipGWlggZrJYZpo1dLh4unNhPxb1LYwc3VHxDAfpWR/lsrktKa3pFnAefmEyoG8fPse75yxz6hLPCrOQpbIH2BxGh7OemUEBFolkewM2eoN59t1BSiw4uyYbufO+oKnc9woxGkbALfPg245J/2aQFP1cb5gWoQv+Rf68T5hxuoGRVHJOzkP6z7WKLOjmBSzh5e0N1WwWR6kqfh/w/JfCokE9+QPYvA9Df8gWB5/1iQ7IVQdWeIDGa1Wlt mPCFULJ/ PJ4jyiszkg21lx7o3KMMXa4E1A0590BqudjUfQnWMw8iLllGH+zO2U5KjpMRt3oPWJA09UsjaKQzjhtwXLzlFkk78CEbP8BgOxTZlOEwaG86pCBKGfrHjQjcAH+P+BVHMaEt2wLeNj6X9hZJuAwnf0eqyiQrklZg0ZNSJ9vhFZ3IuORtiVL9QTdMnxOO/eyFFfYtERavuEQ3y56qYoSlVOO4E/Jd67/J2YFGbQCO6UQkaR48WFDSr/mM6/6W+XCDQtqXGlvcj3vCiJ3ccCivSSH63Yd5Z606g78g+dY+LsUA01/o12JGH182tRVCFLcM085PX6zQqHflhHPEEXiNpYIvhnMLrhxBoYQumW4zdhww+9tsMrjlcuNnVQVh4ElpkS0vlBnLBIniqb+h+DHhgBYYFt6hPyFbuCYZPA4qgLrte289KfTzQbnioSA/Ad+GMoJ55zTzuvd+TVdw= 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 Wed, Jan 8, 2025 at 6:06=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrote= : > > On Wed, Jan 8, 2025 at 5:46=E2=80=AFPM Nhat Pham wrot= e: > > > > On Wed, Jan 8, 2025 at 9:34=E2=80=AFAM Yosry Ahmed wrote: > > > > > > > > > Actually, using the mutex to protect against CPU hotunplug is not too > > > complicated. The following diff is one way to do it (lightly tested). > > > Johannes, Nhat, any preferences between this patch (disabling > > > migration) and the following diff? > > > > I mean if this works, this over migration diasbling any day? :) > > > > > > > > diff --git a/mm/zswap.c b/mm/zswap.c > > > index f6316b66fb236..4d6817c679a54 100644 > > > --- a/mm/zswap.c > > > +++ b/mm/zswap.c > > > @@ -869,17 +869,40 @@ static int zswap_cpu_comp_dead(unsigned int cpu= , > > > struct hlist_node *node) > > > struct zswap_pool *pool =3D hlist_entry(node, struct zswap_po= ol, node); > > > struct crypto_acomp_ctx *acomp_ctx =3D per_cpu_ptr(pool->acom= p_ctx, cpu); > > > > > > + mutex_lock(&acomp_ctx->mutex); > > > if (!IS_ERR_OR_NULL(acomp_ctx)) { > > > if (!IS_ERR_OR_NULL(acomp_ctx->req)) > > > acomp_request_free(acomp_ctx->req); > > > + acomp_ctx->req =3D NULL; > > > if (!IS_ERR_OR_NULL(acomp_ctx->acomp)) > > > crypto_free_acomp(acomp_ctx->acomp); > > > kfree(acomp_ctx->buffer); > > > } > > > + mutex_unlock(&acomp_ctx->mutex); > > > > > > return 0; > > > } > > > > > > +static struct crypto_acomp_ctx *acomp_ctx_get_cpu_locked( > > > + struct crypto_acomp_ctx __percpu *acomp_ctx) > > > +{ > > > + struct crypto_acomp_ctx *ctx; > > > + > > > + for (;;) { > > > + ctx =3D raw_cpu_ptr(acomp_ctx); > > > + mutex_lock(&ctx->mutex); > > > > I'm a bit confused. IIUC, ctx is per-cpu right? What's protecting this > > cpu-local data (including the mutex) from being invalidated under us > > while we're sleeping and waiting for the mutex? > > > > If it is somehow protected, then yeah this seems quite elegant :) > > thought about this again. Could it be the following? > > bool cpus_is_read_locked(void) > { > return percpu_is_read_locked(&cpu_hotplug_lock); > } > > in zswap: > > bool locked =3D cpus_is_read_locked(); > > if (!locked) > cpus_read_lock(); > > .... // do our job > > if (!locked) > cpus_read_unlock(); > > This seems to resolve all three problems: > 1. if our context has held read lock, we won't hold it again; > 2. if other contexts are holding write lock, we wait for the > completion of cpuhotplug > by acquiring read lock > 3. if our context hasn't held a read lock, we hold it. > sorry for the noise. This won't work because percpu_is_read_locked() is a sum: bool percpu_is_read_locked(struct percpu_rw_semaphore *sem) { return per_cpu_sum(*sem->read_count) !=3D 0 && !atomic_read(&sem->b= lock); } EXPORT_SYMBOL_GPL(percpu_is_read_locked); If other CPUs hold the read lock, it will also return true. However, once t= hose CPUs release the lock, our data might still be released by CPU hotplug. This approach would require something like percpu_is_read_locked_by_me() :-= ( > > > > > + if (likely(ctx->req)) > > > + return ctx; > > > + /* Raced with zswap_cpu_comp_dead() on CPU hotunplug = */ > > > + mutex_unlock(&ctx->mutex); > > > + } > > > +} > > > + > > > +static void acomp_ctx_put_unlock(struct crypto_acomp_ctx *ctx) > > > +{ > > > + mutex_unlock(&ctx->mutex); > > > +} > > > + > > > static bool zswap_compress(struct page *page, struct zswap_entry *en= try, > > > struct zswap_pool *pool) > > > { > > > @@ -893,10 +916,7 @@ static bool zswap_compress(struct page *page, > > > struct zswap_entry *entry, > > > gfp_t gfp; > > > u8 *dst; > > > > > > - acomp_ctx =3D raw_cpu_ptr(pool->acomp_ctx); > > > - > > > - mutex_lock(&acomp_ctx->mutex); > > > - > > > + acomp_ctx =3D acomp_ctx_get_cpu_locked(pool->acomp_ctx); > > > dst =3D acomp_ctx->buffer; > > > sg_init_table(&input, 1); > > > sg_set_page(&input, page, PAGE_SIZE, 0); > > > @@ -949,7 +969,7 @@ static bool zswap_compress(struct page *page, > > > struct zswap_entry *entry, > > > else if (alloc_ret) > > > zswap_reject_alloc_fail++; > > > > > > - mutex_unlock(&acomp_ctx->mutex); > > > + acomp_ctx_put_unlock(acomp_ctx); > > > return comp_ret =3D=3D 0 && alloc_ret =3D=3D 0; > > > } > > > > > > @@ -960,9 +980,7 @@ static void zswap_decompress(struct zswap_entry > > > *entry, struct folio *folio) > > > struct crypto_acomp_ctx *acomp_ctx; > > > u8 *src; > > > > > > - acomp_ctx =3D raw_cpu_ptr(entry->pool->acomp_ctx); > > > - mutex_lock(&acomp_ctx->mutex); > > > - > > > + acomp_ctx =3D acomp_ctx_get_cpu_locked(entry->pool->acomp_ctx= ); > > > src =3D zpool_map_handle(zpool, entry->handle, ZPOOL_MM_RO); > > > /* > > Thanks > Barry