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 0E260C3600C for ; Thu, 3 Apr 2025 03:55:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E5B23280005; Wed, 2 Apr 2025 23:55:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E09A9280001; Wed, 2 Apr 2025 23:55:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD23B280005; Wed, 2 Apr 2025 23:55:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B11A4280001 for ; Wed, 2 Apr 2025 23:55:55 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id BECEF81428 for ; Thu, 3 Apr 2025 03:55:55 +0000 (UTC) X-FDA: 83291369070.16.C40E431 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by imf15.hostedemail.com (Postfix) with ESMTP id D63CAA0003 for ; Thu, 3 Apr 2025 03:55:53 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Batw0+Lx; spf=pass (imf15.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.172 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743652554; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0v59Va1cFoo3feF/U2J6uerO13lHWMq+byB3hbt+oPk=; b=vRVEQ0QCk1uZeEFOcVkye3AyzGW+j8/oPO9sUZAbaGdbcQCVbjkFLst+HP8VW0rBAw2w6n gw2rgH7oDLBIz1jKt+uwu6N8iu33gC4GaBF1nqRoFCBn+TybkNYhbZ7TiRrB40lGMYmpnJ byCZHs2+RGdeuuP6CfdlfoQQDEzCrcI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743652554; a=rsa-sha256; cv=none; b=OSu66H4Y0m9rMBWA/lkCLnp8mSU3CEbohHzxSuIaUo/JIEYsF16aQZPbZZOwcN2WWKbhbV +Zd1MpGIyM4Wp/aFTAVTqgHj89HEx7i2zaUN3BCNFG0exY8GFPiAK3ksZBASk+qOr3Mf9q eNXCW7+5xjb5NOKIbkFxwXv2/Gtfp1k= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Batw0+Lx; spf=pass (imf15.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.172 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-7376dd56eccso505791b3a.0 for ; Wed, 02 Apr 2025 20:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1743652553; x=1744257353; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0v59Va1cFoo3feF/U2J6uerO13lHWMq+byB3hbt+oPk=; b=Batw0+LxAdl62ZGsfZ2CMPmJm1IhU+6lLgRGRIYx1zxc/9mc+icDwz9Ix/td09bzmL tkluqASUvC8WRDwDVaLLv7f305fbv1Kz+WzfEOM+VIxGPXulEeOW4JS8wsScT6o2ub1A /PK+HUEz7st5lhFZ8Hf/qkrXsQp/mPWGo5tk8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743652553; x=1744257353; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0v59Va1cFoo3feF/U2J6uerO13lHWMq+byB3hbt+oPk=; b=qUujNH0qc1WhtmMrpBGpBw8GR1to10JyxdQ0AKimJt4j3NIh18fcUM+7UtXwdrutQv IJ/HZxDkbPNg5naze7BmWYowyrTX5OLZNJMGFNmyKQi7alyCKIszOaqnUB/xECjQ6gRZ CKy05bUXIzFq3k7AUgRtTetZV/EZvkwpd/kKd/vjS/JdVbCi+y0q2gBXd889bwliftx1 SiOEocsf6wzMtjpYtp6B4QHzk5WnkCsEPU3uQOa26x4lKE8xWQ4ek1BG7Sr08/LYXSuc fNEWxdTJ8M5ILyc3VkAzBcd4bQ7toerq8oj56sLz0JFEi+auAvGWZHCIIWYwR1VULLSZ JYLA== X-Forwarded-Encrypted: i=1; AJvYcCXhm3wjCYW0SB/mxdcXfv+fY/OO9SwCSXdslL7XuuvKgB6dVsck6zSi+5Z0dtTsr5X+bnb/Oe8VQw==@kvack.org X-Gm-Message-State: AOJu0Ywg7TNA9RqPCqp/R1Z3z7autfZbMpsjf7kheE+k/j4fS2/Rxzbj 8vPtzvTgLyrKf7Ppa6sv4nchMOMl9rChRmsxX9HsUeYhi3oQqM0DREJkl+tACQ== X-Gm-Gg: ASbGncuJLqjZbrElJ2N8iyxUNd4SlZr++EpOUsuTV0+wWFHW1rD77gEor/tTXdArO63 ntUuA0ho2KhpW4Sp7oFKIGcz9FT90j44aOv02C8NAN6JlBIzC8H2Zko8xu+Jg7gb4qSJjnujlM2 DF6XmOGIR4d/9xFaAMkdN2b0PU2SFSzqaZBV/hAQ8+0o153ykSgxZoOXIZ+ctcB/xbY3Ve6dOmh TbSqCTjokIZnaZTNtU7ZKIi23HMaQcsh1y3n+NlrKmmd4RykiXKBvTx0Fc0dBFGx+076FLor0PC xxAX/1ali9bGs4ZzZUlrHCAReirO44VKaoAQQxx8EoM9na4= X-Google-Smtp-Source: AGHT+IEKyJYCmE/ssbDqw9p58PmbfU6BPpsf7THxBdkw3DrXon2fKE3Jl/zXGWBEVCqgwjGAvzv4JA== X-Received: by 2002:a05:6a00:180b:b0:736:baa0:2acd with SMTP id d2e1a72fcca58-73980487652mr31670164b3a.20.1743652552641; Wed, 02 Apr 2025 20:55:52 -0700 (PDT) Received: from google.com ([2401:fa00:8f:203:bb3:abb1:21bc:a00c]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-739da0b3ff9sm383401b3a.137.2025.04.02.20.55.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Apr 2025 20:55:52 -0700 (PDT) Date: Thu, 3 Apr 2025 12:55:46 +0900 From: Sergey Senozhatsky To: Nhat Pham Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, yosry.ahmed@linux.dev, chengming.zhou@linux.dev, sj@kernel.org, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, gourry@gourry.net, ying.huang@linux.alibaba.com, jonathan.cameron@huawei.com, dan.j.williams@intel.com, linux-cxl@vger.kernel.org, minchan@kernel.org, senozhatsky@chromium.org Subject: Re: [PATCH v2] zsmalloc: prefer the the original page's node for compressed data Message-ID: References: <20250402204416.3435994-1-nphamcs@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250402204416.3435994-1-nphamcs@gmail.com> X-Stat-Signature: ik55ii4swk546exrnopbfewtdqdef35q X-Rspam-User: X-Rspamd-Queue-Id: D63CAA0003 X-Rspamd-Server: rspam08 X-HE-Tag: 1743652553-665619 X-HE-Meta: U2FsdGVkX18Jpwf9ew2E/z++mgjQ6ghSgTDDI+yF/THKfwE6s+MhrzB2SMOkrNeibiJ5//z5hWegRBSMzDKxELamv9a2b+KQhiT6EdUP+YsVT0OqeBvbE2dn6ZoKHR1H7rZPuna5POcqq6mWc50e4ZSQmk9NqWbXJx0mC32K47wnr2QaPyro/+vw07hfJnJWAMDvSSm93iVJImQA33bW+70YnJ1PCb3KNPhatOz0wXOYKn8/xmJQQM3oNUcNr9XTbYEl9WvdJVMHDpOV3TAMdihv1MVVOT/bld4eGqQu2Tfml3eYJgDr8t1Xy9XeFL+HRydacfCiZxnRxpudFaT7idLS36/M7rVRTiWkCwIWdwlw34rNOf0MS2uk35gE2+8I0iciM1fhp7jQF6jUpRUQtqnJLe3Af6tgLPwswOC9dcu/YpjVHsfVniZAgR/6vLxJOqPJARQm4JJUrFa2zRlvKqDOYeto5f9QQ5An4Wy1oXyk1VUAmW8L/cCp/lC1wL0iS0Rzha/8bPTva0OFY0FilG8n1SQhUBgTm7lDVEBPAtQGmT5EftqW3v+cbPWiINxbVVfBnRaWyBN0jB2Bi+am7s4IDjxzcYwzc4V/uUJ0xoqqSnnZ5MuvBTvab/Qt5xT5MazJkCdxE4lwUgyKWgwFKBTdIVUZf+byMHVIjVmJcx1LxXB380uX70Dq16JpupLCN9bu5sBFT7ih9qTD5EFDQ9W3AZ9ymuT3CzBiEK8ckPqvY6XTwMrU9Fu8HXA+R6eq6ws5Q77Aeif2YunVDV4oiCKo68ebRJnZ6vgWuk+13CLUZ4yOJAuJpHxd1dcDEIaNDVYNXk/G2d3rF4OMqAnSSOGzciukNZzuATjxSyNwxln6LUKfNrIyNy+i3/P2XDOe7mTiEeRTHLJmc2CvtEZfN+Mh5m45YMxrreRHw7+BbYBf6K3u3goxbcPE0+5vl5gdkBo2nl8Q6TBoi3oK8J8 a+EBg8dF fOtDlo5jNQKk7KGNlpaf4mMqMrv3+Wv5HSLlzd+MJIMb7Vu3tS6YravLna3yRtApG+TOSOe5kvkOFOFYh1NkM3JENozWtYbVXqrC2cO6ZJcGBOD4Fc7o7KXE9zqSYbWfCtyt8bSGYzK99DA5gXV0HeGn5Y9FYxTED+Af2hDr2Svgbo2d2UYWLJX3wFBy/Wfb6Mv7q4oEY6MGeAhxffCX+tb313JNdyNn5DidaRpaBUIIuPLHB/XB19sKrmUMC0lrVGaHe03PTxm0vUHMFYbYAty8zjtlpr3waT3sAWq8+5LG15fweW/QDM0wKN0/EeXZpT9DWwREpyUZHc1Qb+Ik6qZvd+9P4KcHRO7YY 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 (25/04/02 13:44), Nhat Pham wrote: [..] > @@ -1981,10 +1981,15 @@ static int recompress_slot(struct zram *zram, u32 index, struct page *page, > * We are holding per-CPU stream mutex and entry lock so better > * avoid direct reclaim. Allocation error is not fatal since > * we still have the old object in the mem_pool. > + * > + * XXX: technically, the node we really want here is the node that holds > + * the original compressed data. But that would require us to modify > + * zsmalloc API to return this information. For now, we will make do with > + * the node of the page allocated for recompression. > */ > handle_new = zs_malloc(zram->mem_pool, comp_len_new, > GFP_NOIO | __GFP_NOWARN | > - __GFP_HIGHMEM | __GFP_MOVABLE); > + __GFP_HIGHMEM | __GFP_MOVABLE, page_to_nid(page)); This works for me. I saw in other threads (and sorry, I'm on a sick leave now, can't reply fast) that "zram people need to fix it"/etc. I guess I'm one of those zram people and I don't think I run any multi-node NUMA systems, so that problem probably has never occurred to me. We can add a simple API extension to lookup node-id by zsmalloc handle, if anyone really needs it, but I'm okay with the status quo (and XXX) for the time being. [..] > -unsigned long zs_malloc(struct zs_pool *pool, size_t size, gfp_t gfp) > +unsigned long zs_malloc(struct zs_pool *pool, size_t size, gfp_t gfp, > + const int nid) > { I'm not the zspool maintainer, but if I may ask, for new zsmalloc code my preference is to follow the kernel styles (yes, the old code doesn't follow any at all, whenever I touch the old code I fix it). Do you mind if we do something like below? (at least for zsmalloc) With this Acked-by: Sergey Senozhatsky #zram and zsmalloc --- diff --git a/include/linux/zpool.h b/include/linux/zpool.h index 697525cb00bd..369ef068fad8 100644 --- a/include/linux/zpool.h +++ b/include/linux/zpool.h @@ -22,7 +22,7 @@ const char *zpool_get_type(struct zpool *pool); void zpool_destroy_pool(struct zpool *pool); int zpool_malloc(struct zpool *pool, size_t size, gfp_t gfp, - unsigned long *handle, const int nid); + unsigned long *handle, const int nid); void zpool_free(struct zpool *pool, unsigned long handle); @@ -64,7 +64,7 @@ struct zpool_driver { void (*destroy)(void *pool); int (*malloc)(void *pool, size_t size, gfp_t gfp, - unsigned long *handle, const int nid); + unsigned long *handle, const int nid); void (*free)(void *pool, unsigned long handle); void *(*obj_read_begin)(void *pool, unsigned long handle, diff --git a/mm/zpool.c b/mm/zpool.c index b99a7c03e735..0a71d03369f1 100644 --- a/mm/zpool.c +++ b/mm/zpool.c @@ -239,7 +239,7 @@ const char *zpool_get_type(struct zpool *zpool) * Returns: 0 on success, negative value on error. */ int zpool_malloc(struct zpool *zpool, size_t size, gfp_t gfp, - unsigned long *handle, const int nid) + unsigned long *handle, const int nid) { return zpool->driver->malloc(zpool->pool, size, gfp, handle, nid); } diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index daa16ce4cf07..70406ac94bbd 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -452,7 +452,7 @@ static void zs_zpool_destroy(void *pool) } static int zs_zpool_malloc(void *pool, size_t size, gfp_t gfp, - unsigned long *handle, const int nid) + unsigned long *handle, const int nid) { *handle = zs_malloc(pool, size, gfp, nid); @@ -1033,8 +1033,8 @@ static void create_page_chain(struct size_class *class, struct zspage *zspage, * Allocate a zspage for the given size class */ static struct zspage *alloc_zspage(struct zs_pool *pool, - struct size_class *class, - gfp_t gfp, const int nid) + struct size_class *class, + gfp_t gfp, const int nid) { int i; struct zpdesc *zpdescs[ZS_MAX_PAGES_PER_ZSPAGE]; @@ -1333,7 +1333,7 @@ static unsigned long obj_malloc(struct zs_pool *pool, * Allocation requests with size > ZS_MAX_ALLOC_SIZE will fail. */ unsigned long zs_malloc(struct zs_pool *pool, size_t size, gfp_t gfp, - const int nid) + const int nid) { unsigned long handle; struct size_class *class;