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 5795DC2BD09 for ; Fri, 28 Jun 2024 00:51:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AC9326B009C; Thu, 27 Jun 2024 20:51:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A78516B009D; Thu, 27 Jun 2024 20:51:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9404F6B009F; Thu, 27 Jun 2024 20:51:54 -0400 (EDT) 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 706FE6B009C for ; Thu, 27 Jun 2024 20:51:54 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id EC5CBA2CAD for ; Fri, 28 Jun 2024 00:51:53 +0000 (UTC) X-FDA: 82278470106.08.93E114F Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf17.hostedemail.com (Postfix) with ESMTP id EEFF840018 for ; Fri, 28 Jun 2024 00:51:51 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=PHCVivQJ; spf=pass (imf17.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.170 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=1719535903; 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=BnzBmmCKRy0nhaiLP7G/RPc65pcYOuyYQhVZ9ipQNkU=; b=8ajku65yT4SvU5zOy5xHczkoQYGmDI2sQi1J+4eixVxfl+fImJX9hgKP89GBEwBiKN5CB0 9NJMw2y+6QKTc+OB6wrYsyps5ZczmWRQMkKxhuWZCqHzKufKBkugq2wVQvtPPR3E7Fqn2t tO2T9kPa6JUGyU+XUACFWXI3I6UYe+s= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=PHCVivQJ; spf=pass (imf17.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.170 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719535903; a=rsa-sha256; cv=none; b=FzG57r2ruUPbis5cfjSBR0z1kWmg3WOAEMctog901Gb4mG9tROkULM4gdAazbgw5QhaPQ6 fObioMf/1Kdq55E7dMk2EnJ5qAU7bq9q7phZxCZlWQkm9D5RVW+xhKdlUkcj4kC1SEYydu KllLXUHLBxyFXWufcaamCYHeuwnzMq4= Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-1f9b52ef481so185555ad.1 for ; Thu, 27 Jun 2024 17:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1719535911; x=1720140711; 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=BnzBmmCKRy0nhaiLP7G/RPc65pcYOuyYQhVZ9ipQNkU=; b=PHCVivQJHLaxMPdY65y+C4d0BC+cArrzkYudt0GVLg7kKiUgtFWf7ynIAXTcCmEy+j fPgCffRXFCSDoSDM5jzlnxsSAogIs2FjmCwJATfb/hVlTtyMBjFjBaY1/u5DRuumFkh6 TNiD0Iv2dV4Z37VDEl/oxZN7ajfUq1VhAFCjI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719535911; x=1720140711; 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=BnzBmmCKRy0nhaiLP7G/RPc65pcYOuyYQhVZ9ipQNkU=; b=bzl97ANadlQORheEnAuUO7DTqxMEvw5P4vCOyQlZo+WRzf0gxqxChRKTKo1DVM8ZL5 RlUdWHv1YJczFgM8CWg8vmw+aVckjWXPczzfFOBEWT1GPoTmH/V5ZjhMfmwNoom61y66 GBaHTfKgZ3eUwxgvZV6yP6xFJ2cMlNW6GuhPdRPEXADemZQ+Di0qvoCapDXoj5IUoURO 5FvmWuAEFi21Sh2FfUPaDsjZjj3ynTooNU8DGbKTlDQoQAMPCr9rTZwQBUCOr64ZNd36 lLOdUdO8EJp0VWGa9FIHDvM682LAwUQhFCat1CjwXyOco6j9A8BP1P+sMrVJpO3rk3nO rrTg== X-Forwarded-Encrypted: i=1; AJvYcCVUVBrOuhLfRMHgg+j3qH+VtVNK3xbCK56inpYfpWOTL6pkeNhXxnd1PHkodrpWbRo80TMbUbPeCYRt+c+Z1S5GOsg= X-Gm-Message-State: AOJu0Yy/hvXV6ut6WSLUk8NWP6NRKuL44lQu1iTfiZLM3LqHE1qlyZOa Q210PpCe6/KyAAXgQTeOGcx10bxA8q6681nz57/FCOnR+buOKuaSjPUZ3RhVkw== X-Google-Smtp-Source: AGHT+IHH35u2G4jip6EB6h3GWOotvhw5tMMlHtmllGUCZ2Wyxam/1KcQqdMMTBa1nEbOTix8Ou4Fkw== X-Received: by 2002:a17:903:1cf:b0:1f6:f298:e50 with SMTP id d9443c01a7336-1fa23f25727mr158396285ad.58.1719535910675; Thu, 27 Jun 2024 17:51:50 -0700 (PDT) Received: from google.com ([2401:fa00:8f:203:c19a:b9a8:4bd1:72c0]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1fac156957fsm3698755ad.228.2024.06.27.17.51.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Jun 2024 17:51:50 -0700 (PDT) Date: Fri, 28 Jun 2024 09:51:46 +0900 From: Sergey Senozhatsky To: Andrew Morton Cc: Chengming Zhou , minchan@kernel.org, senozhatsky@chromium.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] mm/zsmalloc: fix class per-fullness zspage counts Message-ID: <20240628005146.GB15925@google.com> References: <20240627075959.611783-1-chengming.zhou@linux.dev> <20240627133330.7f8a82078725228585dbf2d3@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240627133330.7f8a82078725228585dbf2d3@linux-foundation.org> X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: EEFF840018 X-Stat-Signature: 16kknj68m1wdpymb6997im9ycfr7omkc X-HE-Tag: 1719535911-188797 X-HE-Meta: U2FsdGVkX1/2MtWk4LWMqojADCoq9c6MK/zy0qrT4r7YJFUGyk77D0rYhMAydTVJnLsPUPaa5rs196sych1+KSbf4sLJRYRMQordiyzSLb3UZU4I0cYHoN5+pv4ySwvTCDMkk9V/yeDmYI9J8nwlM3g4ca3DfNgG/ONwuSwYvlaNPEfF33RH+40iZeZOJT4ovyAr9HzEbNNSIXLQ5HESwbNmGvmNp0gLpXuY0wDXeH6WjUpW46kYARbdyNu2k4ebEGY+Zv2FkKs5yA1DBWWhnUzQKyu/BUe4nW1gDNi8JzcO3Ebp7MacAEylh6/Dax3GoaDQ+Zgq9vsgjCh+TNapUCEkxjm5eT8SE8eB9SOe4f5AL1G8AvXvk4c6+l3cpFH9S+8Uc7Y40yRTnWKmsjMITPvSBZeCfzbvbxcKc2kl60bmED+gpK7wW1bquHcpl/sdxOH2dy95gsEDyC0J9zunTIbuuOx323t+7a05qa9Epp7ykrFgzaSUGUIrjIc/g5NhIlG6gw8Ogu14KHoopAY4HJ7E2tYptykCHafJ4M+6rfOrGgAIg2KWMZEFXed/hb9ln6zz8Z6AFmtL7g3sL6eucPEQ73FDJ5w0XT61/j0forvM+W8E8DYFE4tRZ2FYPmm2qIAGSmNarFVICil8WK9NENlA/Z3q+vfKGoQ1sUq2WkfnHkwbRoVuMc1yCjrlTHu3LJ5X6dMV9/Vd0geuae/7yCBXacC9X5BWkV1/ym0HGF1V6gY73zVpr4NkaIUnAi3i8eCPokysYuJU2iAVkfYnr6HqBV+EdUBsypFHzCcaZY/obP7Gc1nFyd5IMOESBvB3dSKdVTqx1wZVwKq0MSJW2ux72JWjkIEQ+XAyLFFeb9xjiVywg/eZKirT7s6XcJaUfP1upgh8RufX2gHpPJ6+WUL5QdHGPVOf0F8oqWtXjM45+3+z7PDeTvgZr40NyCVcxpatirl0fJoF/osXsoW dcBbsJHn M5MmhR7xT6l7iu3ClzuUoN2W+ZE9hE533GN4Vg+dpxJ/LynHijUCT9HIkKp0cE46u4LfJ2jjcBBb+TPv68W1ZY/KZOox7tf5Rm2T9cAQJrw061kDjNvT8A1XKgoyIyiN1kgOzJD70x8vq8euYPEOni33CA+FV+beMlTpydiGFrrFsJauDdfiBgXr7yvYOWXIFw9rCsRu1u7F3GWolOlqvkd0wpzDjs5UkCnaArV4YNXY1cFqeZNdB6+zwv0zQX2RUUUattFrtC4uTiQ8IVk9eeszDVN7XqfE54F1ulaP2Jkv5WVmQCgYODRSHKK6xcTc10Pos8qSSjzj5LzY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000554, 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 (24/06/27 13:33), Andrew Morton wrote: > On Thu, 27 Jun 2024 15:59:58 +0800 Chengming Zhou wrote: > > We always use insert_zspage() and remove_zspage() to update zspage's > > fullness location, which will account correctly. > > > > But this special async free path use "splice" instead of remove_zspage(), > > so the per-fullness zspage count for ZS_INUSE_RATIO_0 won't decrease. > > > > Fix it by decreasing when iterate over the zspage free list. > > > > ... > > > > Signed-off-by: Chengming Zhou > > +++ b/mm/zsmalloc.c > > @@ -1883,6 +1883,7 @@ static void async_free_zspage(struct work_struct *work) > > > > class = zspage_class(pool, zspage); > > spin_lock(&class->lock); > > + class_stat_dec(class, ZS_INUSE_RATIO_0, 1); > > __free_zspage(pool, class, zspage); > > spin_unlock(&class->lock); > > } > > What are the runtime effects of this bug? Should we backport the fix > into earlier kernels? And are we able to identify the appropriate > Fixes: target? I don't think this has any run-time visible effects. Class stats (ZS_OBJS_ALLOCATED and ZS_OBJS_INUSE) play their role during compaction (defragmentation), but ZS_INUSE_RATIO_0 is for zspage fullness type, moreover for empty zspage, which we don't look at during compaction. With CONFIG_ZSMALLOC_STAT enabled we show pool/class stats to the users via zs_stats_size_show() but ZS_INUSE_RATIO_0 is ignored. So no one (external) should know what value is there and ZS_INUSE_RATIO_0 should never be of any importance to zsmalloc (internally). Code in question (async_free_zspage()) was introduced by 48b4800a1c6af in 2016-07-26, so it's been a long time.