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 98570D64084 for ; Fri, 8 Nov 2024 20:23:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D447900007; Fri, 8 Nov 2024 15:23:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 282328D0001; Fri, 8 Nov 2024 15:23:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 105A4900007; Fri, 8 Nov 2024 15:23:01 -0500 (EST) 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 DCE3D8D0001 for ; Fri, 8 Nov 2024 15:23:00 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9E2111C643D for ; Fri, 8 Nov 2024 20:23:00 +0000 (UTC) X-FDA: 82764050334.25.E795DFB Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) by imf02.hostedemail.com (Postfix) with ESMTP id 8890D80006 for ; Fri, 8 Nov 2024 20:21:48 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=urxSftjy; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of yosryahmed@google.com designates 209.85.210.49 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731097207; 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=j2hzwMt1vCXwnRJDBw66UYNW1buQGS3Aq1RmBj4RhN4=; b=1r+nTV00njIZ6oFXVDlQMWyZyE+1DDIdLJsmWGrt9KzVv7phQRFr+msoDPjccQMnPrw4z6 5oHi+6zxYZy5yzixj8XwpbcaUCCDef7b1FqHKr6loleNPfA+7+zYffVntw53agh99LSbFA Rsjf3FMxTnNGdRPP07vbYU/Y3X1l7AM= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=urxSftjy; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of yosryahmed@google.com designates 209.85.210.49 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731097207; a=rsa-sha256; cv=none; b=Qc+xhWahfTROtCRnI8eFfO0Ds1d9vCeYVTT9Q7yqUpzFDuYtmXTuHN8ugmyML1ikPYgbRO SD3xIwp9xBZxnsy6bMxpV4nYvufgAzoWScSCBxi/pRa2y5szPdAAHfIn3GAxb0BfK4WrNR FMc0zt2R9m75/oOYSRMBj9zie+PrQyU= Received: by mail-ot1-f49.google.com with SMTP id 46e09a7af769-71815313303so1597532a34.1 for ; Fri, 08 Nov 2024 12:22:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1731097378; x=1731702178; 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=j2hzwMt1vCXwnRJDBw66UYNW1buQGS3Aq1RmBj4RhN4=; b=urxSftjyQgNGXkDzexqTSEsoSgNQTzfuD+JCkQsd/WfPSbZ122Osj2qNC7WaHCj7wh OEmJ3acjtazI3s12zMd4jBTLpjXkj5GzjWth8MdsylWGsR+wdpq1Ss1YE1wcmZWblEBB SubmTwcBnUqo9+wdfs8c7eC8Yf9DhpGFIM6xOVqNGM4XM7sMZvkhxHMItLmOyYyXou5D WXwAhueQ5D5xTXS5nNFrzF8nU7xWQLc1JlobyjVBYKQHfon+vBVJR49CEF6iFc3P/zKu li04Kqs1S8Q2mBUV5bXk9KPFGIQqIRJCTAWAvL+pu8FbjYi1LYnkbJEwmSW6dQ8QnBtG /8vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731097378; x=1731702178; 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=j2hzwMt1vCXwnRJDBw66UYNW1buQGS3Aq1RmBj4RhN4=; b=Me9aLNGhGQMI5W64mxNZAL/E5gMdzEq+PyK+AWLav5YV1KaULjZERU8KbOGK5RL4Pg 9BdfvAPOvs0kkK9T4Nceo5MGD4jPwGKDWrX4E/gIyDBH5xBwfOVbYcOjEyJNppCwPS6k 6kI8w+5bac257fMyJ4jGip06RQoEEHTl+KCyV5Ly8P7S7wqHb967ThPU/OediDLWwFRo 6QFttQkz42VPgWs/RGufcpg+DViuWsz6ITyUXlyCVka2rXW2FdsVfu0/0XK8m22JIACf GRBKIVWhXioEmdt2K/m0htB6LIyQnQiZorOFUvn2lIs5CmJpjM01YBdZGnslRUQnhNNf DrYw== X-Forwarded-Encrypted: i=1; AJvYcCW5pibLPLLtTE5lJXsTmp6D5CISHThbWTlpxk0aFhyRoBDtOtH47fa1wwMfW0zBrqhkqtz8k/q8ow==@kvack.org X-Gm-Message-State: AOJu0YzWh1c/E5uzlMja/sdOf/rrFFrZkZtvbbPv3t1XeX2q5Lr+ZEtq u2ubTqsR2Y9PxnkKP+M/62jFx/PLKsbiLnzQ6UjV36AJICzzrSDF/c8ZNAaZGenfKPKUIDFeFJW At8NTQ/yShM+NVYmjbFEO6tidxQcxAQTTpXrp X-Google-Smtp-Source: AGHT+IFjyt9auLSTN4OrHmI8xBiTct7D6gWyd04J3d54pyx6QKB4P4jpozUdfP8sQsvTQ9DB0xUuNIhWiKVawHd0fqg= X-Received: by 2002:a05:6358:5d84:b0:1bc:d0a4:3d3a with SMTP id e5c5f4694b2df-1c641ec23bcmr361609655d.12.1731097377665; Fri, 08 Nov 2024 12:22:57 -0800 (PST) MIME-Version: 1.0 References: <20241106192105.6731-1-kanchana.p.sridhar@intel.com> <20241106192105.6731-10-kanchana.p.sridhar@intel.com> <20241107172056.GC1172372@cmpxchg.org> In-Reply-To: From: Yosry Ahmed Date: Fri, 8 Nov 2024 12:22:21 -0800 Message-ID: Subject: Re: [PATCH v3 09/13] mm: zswap: Modify struct crypto_acomp_ctx to be configurable in nr of acomp_reqs. To: "Sridhar, Kanchana P" Cc: Johannes Weiner , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "nphamcs@gmail.com" , "chengming.zhou@linux.dev" , "usamaarif642@gmail.com" , "ryan.roberts@arm.com" , "Huang, Ying" , "21cnbao@gmail.com" <21cnbao@gmail.com>, "akpm@linux-foundation.org" , "linux-crypto@vger.kernel.org" , "herbert@gondor.apana.org.au" , "davem@davemloft.net" , "clabbe@baylibre.com" , "ardb@kernel.org" , "ebiggers@google.com" , "surenb@google.com" , "Accardi, Kristen C" , "zanussi@kernel.org" , "Feghali, Wajdi K" , "Gopal, Vinodh" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 8890D80006 X-Stat-Signature: 7riycwr81fw4mwbcutkxd19bf9q1ya37 X-Rspam-User: X-HE-Tag: 1731097308-810071 X-HE-Meta: U2FsdGVkX19pIZ+bkfect1zMPNucUOwfyfnAndte8iagf+02oHjuScz7C+oW9eCq/YHCBpHGDXXdMFWG2PKqMn9j5bsHX57IYfyJ7cAFNfOyYATDSNW3gBdzaT2I3mNg+4SbbFTlxAJrieLk70+qdBH8NLLOfEk052T76oK+Xr2KoankABqEDqtqJ/Io/z4+NsAj1NX6XeVDnVhthLldsqrAewcaX6YVyMtQTLDLIMC9O7ZHwxIOPVo6Pgl1wvkJcoT2Yo+FvUBThbtnzym9XWSy/yFKeWzSlmsw3yxtL6/gu3OY3+GbYEPxnNT69JTQgklBl0RF9CHfuW8aenvNc4hFyYlMQAz1HEZyenlxPJRSYKr3n0ps6oHqO/rDQvsKFwlkhipIE3tqsrbk5WHCWoAv0fqCBndaOiYJgnMd3Zd0oO3NmCmk1G1h6rLqwIAz4ctuizFtg7OgVtMahuW7iiua7qZT9ds753lvQkai6GIhhyeeuw0ZVTi2JUrTsXrbZy7+WS4svwEyZRs4xzlXzl3Lj76ZcN/IcKjESQpSIUOG5Hk9iHb3Z+17lt68BABMsynh+5Jd2SJqhP5MqGbGJR74Npb7mtS+fkwspu0nE5piuVkvcl6N9xxX1JKTJuvq7TE4N6DAoVcvgcVS1IJWebu1G3tYoQGtcMrX3n3DQ/bVN3o1tmzdXWL6Ut5NH106s9DMwJGJWhbzW2x47L/b8+Uip4eGRlFAkRpdofoCNdaMqXw+6BH86eIA3xZ3ZWDIJE5RK4TUQ7OB8R/rsiwLuMNDKLKbm9jXVj/yIIgFDntVU69Ny+q3VshWA/mznFvL7gqjATF7/x+iQfpCIRrah9sDx1AR+DnhSEj35u75APLIxne6QsvBRTOfFwhCKSzt5v4ohkDhpIy6x859E9Iv7E7cNi2I8WrUWgYgqlxCN33f/feUlj5bjhyR0LVcsdDLfe3LYT4mv91JVH4RL69 82HmMOop PKBQsGXTGf1mibPWtk9ISS4p0qNkaytq0AeFwoFGki4hsUuiJvpVFO2NDm1x6aQdvAcnC1Yu4XHItiyvLgdr+CSCe9BfCcxeAozFfNjbyIjceqjjuOyg5g6Qcy4jcHgA7YsDJh6IlNVoNLEaJUhadPr2W+/ZIT7W9gXVL6klCE846oSpCnJGWJi/0W9qhwCFOC2MvbBq329O+XKWD5Z+MbxreULyNYEnd8VkIeu9mmNV8Ptbg2nmMOZV0oqJtm1C2NqJ/sLIyJaLao5TKZe8DdibCEHF7cpyY7oi3FMRyV6u3vMi8WEb04T9gpn4JY5ybeLSZT6sN4SvwjC3ixXLPwOXNDO9BL2XZriPH4YDGXWfHMiDP1dwGZq/FA1N7e9WNksPhvo9RCmihEsLvL607DsO7BQg/yY2DgY5oV+2jK5Gy14h48tb2HaFCOzPtWyg2tsWY8EMUpUTlmowxmmxVn6DUtMkEK4OH78Qr94L+EIwDawOBl7jCAHCiT7QkzBPbIOECOPXW3DgR3a5lWPud+ovM90fvQr6XT6RNDtm7qMonD6YIql0sXkXkEfOCTxscuksCQ54SPrMUHr3m1gLkhDgyg5nQ86ICPk3ZpQeesU0Ev658M/jJqUER6xxHZQgfaeBfHZSs3ZXsMFNa52Jc8TtMQRVltKMBnH/bUjhaRvImceKXD17ffwHtU9V6OPminsNfrXLFUKK6S/AVFR3juA1tQmotTiUN0paOwy+VwjpMgPVF9UAKNVK+Z4qF4P/Z0/DurCP66WdaCP14+d/TD9pkQ+0Vs9DM11SH 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 Thu, Nov 7, 2024 at 2:21=E2=80=AFPM Sridhar, Kanchana P wrote: > > Hi Johannes, > > > -----Original Message----- > > From: Johannes Weiner > > Sent: Thursday, November 7, 2024 9:21 AM > > To: Sridhar, Kanchana P > > Cc: linux-kernel@vger.kernel.org; linux-mm@kvack.org; > > yosryahmed@google.com; nphamcs@gmail.com; > > chengming.zhou@linux.dev; usamaarif642@gmail.com; > > ryan.roberts@arm.com; Huang, Ying ; > > 21cnbao@gmail.com; akpm@linux-foundation.org; linux- > > crypto@vger.kernel.org; herbert@gondor.apana.org.au; > > davem@davemloft.net; clabbe@baylibre.com; ardb@kernel.org; > > ebiggers@google.com; surenb@google.com; Accardi, Kristen C > > ; zanussi@kernel.org; Feghali, Wajdi K > > ; Gopal, Vinodh > > Subject: Re: [PATCH v3 09/13] mm: zswap: Modify struct crypto_acomp_ctx > > to be configurable in nr of acomp_reqs. > > > > On Wed, Nov 06, 2024 at 11:21:01AM -0800, Kanchana P Sridhar wrote: > > > Modified the definition of "struct crypto_acomp_ctx" to represent a > > > configurable number of acomp_reqs and the required number of buffers. > > > > > > Accordingly, refactored the code that allocates/deallocates the acomp= _ctx > > > resources, so that it can be called to create a regular acomp_ctx wit= h > > > exactly one acomp_req/buffer, for use in the the existing non-batchin= g > > > zswap_store(), as well as to create a separate "batching acomp_ctx" w= ith > > > multiple acomp_reqs/buffers for IAA compress batching. > > > > > > Signed-off-by: Kanchana P Sridhar > > > --- > > > mm/zswap.c | 149 ++++++++++++++++++++++++++++++++++++++---------- > > ----- > > > 1 file changed, 107 insertions(+), 42 deletions(-) > > > > > > diff --git a/mm/zswap.c b/mm/zswap.c > > > index 3e899fa61445..02e031122fdf 100644 > > > --- a/mm/zswap.c > > > +++ b/mm/zswap.c > > > @@ -143,9 +143,10 @@ bool zswap_never_enabled(void) > > > > > > struct crypto_acomp_ctx { > > > struct crypto_acomp *acomp; > > > - struct acomp_req *req; > > > + struct acomp_req **reqs; > > > + u8 **buffers; > > > + unsigned int nr_reqs; > > > struct crypto_wait wait; > > > - u8 *buffer; > > > struct mutex mutex; > > > bool is_sleepable; > > > }; > > > @@ -241,6 +242,11 @@ static inline struct xarray > > *swap_zswap_tree(swp_entry_t swp) > > > pr_debug("%s pool %s/%s\n", msg, (p)->tfm_name, \ > > > zpool_get_type((p)->zpool)) > > > > > > +static int zswap_create_acomp_ctx(unsigned int cpu, > > > + struct crypto_acomp_ctx *acomp_ctx, > > > + char *tfm_name, > > > + unsigned int nr_reqs); > > > > This looks unnecessary. > > Thanks for the code review comments. I will make sure to avoid the > forward declarations. > > > > > > + > > > /********************************* > > > * pool functions > > > **********************************/ > > > @@ -813,69 +819,128 @@ static void zswap_entry_free(struct > > zswap_entry *entry) > > > /********************************* > > > * compressed storage functions > > > **********************************/ > > > -static int zswap_cpu_comp_prepare(unsigned int cpu, struct hlist_nod= e > > *node) > > > +static int zswap_create_acomp_ctx(unsigned int cpu, > > > + struct crypto_acomp_ctx *acomp_ctx, > > > + char *tfm_name, > > > + unsigned int nr_reqs) > > > { > > > - struct zswap_pool *pool =3D hlist_entry(node, struct zswap_pool, > > node); > > > - struct crypto_acomp_ctx *acomp_ctx =3D per_cpu_ptr(pool- > > >acomp_ctx, cpu); > > > struct crypto_acomp *acomp; > > > - struct acomp_req *req; > > > - int ret; > > > + int ret =3D -ENOMEM; > > > + int i, j; > > > > > > + acomp_ctx->nr_reqs =3D 0; > > > mutex_init(&acomp_ctx->mutex); > > > > > > - acomp_ctx->buffer =3D kmalloc_node(PAGE_SIZE * 2, GFP_KERNEL, > > cpu_to_node(cpu)); > > > - if (!acomp_ctx->buffer) > > > - return -ENOMEM; > > > - > > > - acomp =3D crypto_alloc_acomp_node(pool->tfm_name, 0, 0, > > cpu_to_node(cpu)); > > > + acomp =3D crypto_alloc_acomp_node(tfm_name, 0, 0, > > cpu_to_node(cpu)); > > > if (IS_ERR(acomp)) { > > > pr_err("could not alloc crypto acomp %s : %ld\n", > > > - pool->tfm_name, PTR_ERR(acomp)); > > > - ret =3D PTR_ERR(acomp); > > > - goto acomp_fail; > > > + tfm_name, PTR_ERR(acomp)); > > > + return PTR_ERR(acomp); > > > } > > > + > > > acomp_ctx->acomp =3D acomp; > > > acomp_ctx->is_sleepable =3D acomp_is_async(acomp); > > > > > > - req =3D acomp_request_alloc(acomp_ctx->acomp); > > > - if (!req) { > > > - pr_err("could not alloc crypto acomp_request %s\n", > > > - pool->tfm_name); > > > - ret =3D -ENOMEM; > > > + acomp_ctx->buffers =3D kmalloc_node(nr_reqs * sizeof(u8 *), > > > + GFP_KERNEL, cpu_to_node(cpu)); > > > + if (!acomp_ctx->buffers) > > > + goto buf_fail; > > > + > > > + for (i =3D 0; i < nr_reqs; ++i) { > > > + acomp_ctx->buffers[i] =3D kmalloc_node(PAGE_SIZE * 2, > > > + GFP_KERNEL, > > cpu_to_node(cpu)); > > > + if (!acomp_ctx->buffers[i]) { > > > + for (j =3D 0; j < i; ++j) > > > + kfree(acomp_ctx->buffers[j]); > > > + kfree(acomp_ctx->buffers); > > > + ret =3D -ENOMEM; > > > + goto buf_fail; > > > + } > > > + } > > > + > > > + acomp_ctx->reqs =3D kmalloc_node(nr_reqs * sizeof(struct acomp_re= q > > *), > > > + GFP_KERNEL, cpu_to_node(cpu)); > > > + if (!acomp_ctx->reqs) > > > goto req_fail; > > > + > > > + for (i =3D 0; i < nr_reqs; ++i) { > > > + acomp_ctx->reqs[i] =3D acomp_request_alloc(acomp_ctx- > > >acomp); > > > + if (!acomp_ctx->reqs[i]) { > > > + pr_err("could not alloc crypto acomp_request > > reqs[%d] %s\n", > > > + i, tfm_name); > > > + for (j =3D 0; j < i; ++j) > > > + acomp_request_free(acomp_ctx->reqs[j]); > > > + kfree(acomp_ctx->reqs); > > > + ret =3D -ENOMEM; > > > + goto req_fail; > > > + } > > > } > > > - acomp_ctx->req =3D req; > > > > > > + /* > > > + * The crypto_wait is used only in fully synchronous, i.e., with = scomp > > > + * or non-poll mode of acomp, hence there is only one "wait" per > > > + * acomp_ctx, with callback set to reqs[0], under the assumption = that > > > + * there is at least 1 request per acomp_ctx. > > > + */ > > > crypto_init_wait(&acomp_ctx->wait); > > > /* > > > * if the backend of acomp is async zip, crypto_req_done() will > > wakeup > > > * crypto_wait_req(); if the backend of acomp is scomp, the callb= ack > > > * won't be called, crypto_wait_req() will return without blockin= g. > > > */ > > > - acomp_request_set_callback(req, > > CRYPTO_TFM_REQ_MAY_BACKLOG, > > > + acomp_request_set_callback(acomp_ctx->reqs[0], > > CRYPTO_TFM_REQ_MAY_BACKLOG, > > > crypto_req_done, &acomp_ctx->wait); > > > > > > + acomp_ctx->nr_reqs =3D nr_reqs; > > > return 0; > > > > > > req_fail: > > > + for (i =3D 0; i < nr_reqs; ++i) > > > + kfree(acomp_ctx->buffers[i]); > > > + kfree(acomp_ctx->buffers); > > > +buf_fail: > > > crypto_free_acomp(acomp_ctx->acomp); > > > -acomp_fail: > > > - kfree(acomp_ctx->buffer); > > > return ret; > > > } > > > > > > -static int zswap_cpu_comp_dead(unsigned int cpu, struct hlist_node > > *node) > > > +static void zswap_delete_acomp_ctx(struct crypto_acomp_ctx > > *acomp_ctx) > > > { > > > - struct zswap_pool *pool =3D hlist_entry(node, struct zswap_pool, > > node); > > > - struct crypto_acomp_ctx *acomp_ctx =3D per_cpu_ptr(pool- > > >acomp_ctx, cpu); > > > - > > > if (!IS_ERR_OR_NULL(acomp_ctx)) { > > > - if (!IS_ERR_OR_NULL(acomp_ctx->req)) > > > - acomp_request_free(acomp_ctx->req); > > > + int i; > > > + > > > + for (i =3D 0; i < acomp_ctx->nr_reqs; ++i) > > > + if (!IS_ERR_OR_NULL(acomp_ctx->reqs[i])) > > > + acomp_request_free(acomp_ctx->reqs[i]); > > > + kfree(acomp_ctx->reqs); > > > + > > > + for (i =3D 0; i < acomp_ctx->nr_reqs; ++i) > > > + kfree(acomp_ctx->buffers[i]); > > > + kfree(acomp_ctx->buffers); > > > + > > > if (!IS_ERR_OR_NULL(acomp_ctx->acomp)) > > > crypto_free_acomp(acomp_ctx->acomp); > > > - kfree(acomp_ctx->buffer); > > > + > > > + acomp_ctx->nr_reqs =3D 0; > > > + acomp_ctx =3D NULL; > > > } > > > +} > > > + > > > +static int zswap_cpu_comp_prepare(unsigned int cpu, struct hlist_nod= e > > *node) > > > +{ > > > + struct zswap_pool *pool =3D hlist_entry(node, struct zswap_pool, > > node); > > > + struct crypto_acomp_ctx *acomp_ctx; > > > + > > > + acomp_ctx =3D per_cpu_ptr(pool->acomp_ctx, cpu); > > > + return zswap_create_acomp_ctx(cpu, acomp_ctx, pool->tfm_name, > > 1); > > > +} > > > + > > > +static int zswap_cpu_comp_dead(unsigned int cpu, struct hlist_node > > *node) > > > +{ > > > + struct zswap_pool *pool =3D hlist_entry(node, struct zswap_pool, > > node); > > > + struct crypto_acomp_ctx *acomp_ctx; > > > + > > > + acomp_ctx =3D per_cpu_ptr(pool->acomp_ctx, cpu); > > > + zswap_delete_acomp_ctx(acomp_ctx); > > > > > > return 0; > > > } > > > > There are no other callers to these functions. Just do the work > > directly in the cpu callbacks here like it used to be. > > There will be other callers to zswap_create_acomp_ctx() and > zswap_delete_acomp_ctx() in patches 10 and 11 of this series, when the > per-cpu "acomp_batch_ctx" is introduced in struct zswap_pool. I was tryin= g > to modularize the code first, so as to split the changes into smaller com= mits. > > The per-cpu "acomp_batch_ctx" resources are allocated in patch 11 in the > "zswap_pool_can_batch()" function, that allocates batching resources > for this cpu. This was to address Yosry's earlier comment about minimizin= g > the memory footprint cost of batching. > > The way I decided to do this is by reusing the code that allocates the de= -facto > pool->acomp_ctx for the selected compressor for all cpu's in zswap_pool_c= reate(). > However, I did not want to add the acomp_batch_ctx multiple reqs/buffers > allocation to the cpuhp_state_add_instance() code path which would incur = the > memory cost on all cpu's. > > Instead, the approach I chose to follow is to allocate the batching resou= rces > in patch 11 only as needed, on "a given cpu" that has to store a large fo= lio. Hope > this explains the purpose of the modularization better. > > Other ideas towards accomplishing this are very welcome. If we remove the sysctl as suggested by Johannes, then we can just allocate the number of buffers based on the compressor and whether it supports batching during the pool initialization in the cpu callbacks only. Right? > > Thanks, > Kanchana > > > > > Otherwise it looks good to me.