Message ID | 20230223030451.543162-6-senozhatsky@chromium.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp85965wrd; Wed, 22 Feb 2023 19:06:08 -0800 (PST) X-Google-Smtp-Source: AK7set89vwwthuNF1cuw2uyn4nAyS+BtY2LEn/kyazGRsVTsX9PFC40saox1gs16n7vkK/X0Fgdw X-Received: by 2002:a17:906:8601:b0:89c:d072:e33e with SMTP id o1-20020a170906860100b0089cd072e33emr16384981ejx.49.1677121567856; Wed, 22 Feb 2023 19:06:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677121567; cv=none; d=google.com; s=arc-20160816; b=MAsolrddTztv1ImVznlkC/CNzhjVnizcoVJzh6wHXJs8GcUNv4WhSoQboCdKIYAuEd zktp9qNnL9KlTRgvnizTHp6zQXhvgA1Q65ekTzBnwMbKiV+YzMEWYHJX4UgHRVewRjUL Kf0NHdE+PFghm8/1/az0Rp51UfJc23hvikt2PpFcg/offH2fasOYJhpT2Obc4SJ3nR4P Q/7jo7HbdfYuOb+3oqOxlI5+REUicJg7fmIslFFyYFwQLZjPWsZpyU3SjTkpV7ZoSusg ZQt3pnXoTdTUwey/RTdyXOxbEmVwyMKmDynRorrgIDvbpQFYZU8jV+XY+XIza0n3mMk4 d5DQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=BpGG/okMdj5ni9xegYLzCx8QuNxJjUnFEqNX1SXn5aY=; b=ehobV1HrRisMRVzCIwgZTyGsmIPGbsHvn/jzZbRDGs4ii/lpVd5yJ8RJEdMa93aU8p cu3he4xrgnrEgL/X6N/1OTnk0xz2aD0HKhP0hJhQCdR9rnd/3Jt9iqeKnJaCiStWlEzl hhlI8euGcVCYhHI4A6e2BZ/smOAABaSyKewWzoP8hztf78qESI5rOtXNyTaNHSF/Fj3H r5/FDNP4rC/ldUdR/T6QlFlW2N3LgItXZsqCGwYygow5fLDWN+EsdGK31/lLQrGe9BPw m0sAXk7g9tKPDSCTS5gHP61MQq6a5/AjUO2vSBZoSRwlJ13b8BqMlHQGFyDA8ldXlKtg dSlg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=eXWiDf6C; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v23-20020a17090651d700b008b17ac6b0fbsi22328609ejk.512.2023.02.22.19.05.44; Wed, 22 Feb 2023 19:06:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=eXWiDf6C; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233044AbjBWDFc (ORCPT <rfc822;chinmaygameti@gmail.com> + 99 others); Wed, 22 Feb 2023 22:05:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51198 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233883AbjBWDFS (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 22 Feb 2023 22:05:18 -0500 Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A00B34740C for <linux-kernel@vger.kernel.org>; Wed, 22 Feb 2023 19:05:12 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id i10so2359460plr.9 for <linux-kernel@vger.kernel.org>; Wed, 22 Feb 2023 19:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=BpGG/okMdj5ni9xegYLzCx8QuNxJjUnFEqNX1SXn5aY=; b=eXWiDf6CYI70E3qaKKdmQKpYXcXl5mJcHwRXnE9PqLSpLMIBznVHG6rsd6Yik0X/kL 7XBQaZKnWMaK+ZCn7rGTemi+XWQrhgo9ktJrz62HQnL1ZI8wqWskCMnCOUoRKkFs/oq2 x5q7YV9lJ90uWhY6HMhvkqjtbT42l++wXe/Sg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BpGG/okMdj5ni9xegYLzCx8QuNxJjUnFEqNX1SXn5aY=; b=K31aiZZT3KDW4nh5Yb11W7XXuBgF+3+vkIbnAz9Dx4Fxb45JIrMPSV/4C03YMaKGJj czrS/mEmu4ZAHuulthxubrCSB3Esnv18VYybS4DFPGETw9mAH2wyQiYvglGN1Xhowm3t Zm6cOpay9J1N0uWzjCSANdZCvFQwu3CpejLaUJ+uYxrwQjbh5bwKgYeRSKLLiRIXBeD2 1YJijpnD2UJZJ7SkIm44yQ8g0sZ916+5nqfMLTSqODBL75vrd/SeweFPrBPDSrGpcrAt fy44QvE5NO/yQf6OZt+fwpvdA6UolxGU21f/e7TkJ8zi896HuooS6iwYLK+b8jwZ27jL ktbw== X-Gm-Message-State: AO0yUKWrTDw1LVGi0XyO4woD59knjuxIBCvvmiHPr3mpLph7MEHk2l2v uTi3awTVq7qnk8NQ2S6S9VkNLGiwBdsnFQ7M X-Received: by 2002:a17:902:e5c9:b0:19c:355c:6eb5 with SMTP id u9-20020a170902e5c900b0019c355c6eb5mr14014208plf.30.1677121512118; Wed, 22 Feb 2023 19:05:12 -0800 (PST) Received: from tigerii.tok.corp.google.com ([2401:fa00:8f:203:6de2:9e85:b508:57b8]) by smtp.gmail.com with ESMTPSA id jl21-20020a170903135500b0019926c77577sm608520plb.90.2023.02.22.19.05.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Feb 2023 19:05:11 -0800 (PST) From: Sergey Senozhatsky <senozhatsky@chromium.org> To: Minchan Kim <minchan@kernel.org>, Andrew Morton <akpm@linux-foundation.org> Cc: Yosry Ahmed <yosryahmed@google.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Sergey Senozhatsky <senozhatsky@chromium.org> Subject: [PATCHv2 5/6] zsmalloc: extend compaction statistics Date: Thu, 23 Feb 2023 12:04:50 +0900 Message-Id: <20230223030451.543162-6-senozhatsky@chromium.org> X-Mailer: git-send-email 2.39.2.637.g21b0678d19-goog In-Reply-To: <20230223030451.543162-1-senozhatsky@chromium.org> References: <20230223030451.543162-1-senozhatsky@chromium.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758589425242190925?= X-GMAIL-MSGID: =?utf-8?q?1758589425242190925?= |
Series |
zsmalloc: fine-grained fullness and new compaction algorithm
|
|
Commit Message
Sergey Senozhatsky
Feb. 23, 2023, 3:04 a.m. UTC
Extend zsmalloc zs_pool_stats with a new member that
holds the number of objects pool compaction moved
between pool pages.
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
---
include/linux/zsmalloc.h | 2 ++
mm/zsmalloc.c | 1 +
2 files changed, 3 insertions(+)
Comments
On Thu, Feb 23, 2023 at 12:04:50PM +0900, Sergey Senozhatsky wrote: > Extend zsmalloc zs_pool_stats with a new member that > holds the number of objects pool compaction moved > between pool pages. I totally understand this new stat would be very useful for your development but not sure it's really useful for workload tune or monitoring. Unless we have strong usecase, I'd like to avoid new stat. > > Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> > --- > include/linux/zsmalloc.h | 2 ++ > mm/zsmalloc.c | 1 + > 2 files changed, 3 insertions(+) > > diff --git a/include/linux/zsmalloc.h b/include/linux/zsmalloc.h > index a48cd0ffe57d..8b3fa5b4a68c 100644 > --- a/include/linux/zsmalloc.h > +++ b/include/linux/zsmalloc.h > @@ -36,6 +36,8 @@ enum zs_mapmode { > struct zs_pool_stats { > /* How many pages were migrated (freed) */ > atomic_long_t pages_compacted; > + /* How many objects were migrated during compaction */ > + atomic_long_t objs_moved; > }; > > struct zs_pool; > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c > index eacf9e32da5c..f7e69df48fb0 100644 > --- a/mm/zsmalloc.c > +++ b/mm/zsmalloc.c > @@ -1815,6 +1815,7 @@ static void migrate_zspage(struct zs_pool *pool, struct size_class *class, > obj_idx++; > record_obj(handle, free_obj); > obj_free(class->size, used_obj, NULL); > + atomic_long_inc(&pool->stats.objs_moved); > }
On (23/02/23 15:51), Minchan Kim wrote: > On Thu, Feb 23, 2023 at 12:04:50PM +0900, Sergey Senozhatsky wrote: > > Extend zsmalloc zs_pool_stats with a new member that > > holds the number of objects pool compaction moved > > between pool pages. > > I totally understand this new stat would be very useful for your > development but not sure it's really useful for workload tune or > monitoring. > > Unless we have strong usecase, I'd like to avoid new stat. The way I see is that it *can* give some interesting additional data to periodical compaction (the one is not triggeed by the shrinker): if the number of moves objects is relatively high but the number of comapcted (feeed) pages is relatively low then the system has fragmentation in small size classes (that tend to have many objects per zspage but not too many pages per zspage) and in this case the interval between periodical compactions probably can be increased. What do you think?
On Sun, Feb 26, 2023 at 12:55:45PM +0900, Sergey Senozhatsky wrote: > On (23/02/23 15:51), Minchan Kim wrote: > > On Thu, Feb 23, 2023 at 12:04:50PM +0900, Sergey Senozhatsky wrote: > > > Extend zsmalloc zs_pool_stats with a new member that > > > holds the number of objects pool compaction moved > > > between pool pages. > > > > I totally understand this new stat would be very useful for your > > development but not sure it's really useful for workload tune or > > monitoring. > > > > Unless we have strong usecase, I'd like to avoid new stat. > > The way I see is that it *can* give some interesting additional data to > periodical compaction (the one is not triggeed by the shrinker): if the > number of moves objects is relatively high but the number of comapcted > (feeed) pages is relatively low then the system has fragmentation in > small size classes (that tend to have many objects per zspage but not > too many pages per zspage) and in this case the interval between > periodical compactions probably can be increased. What do you think? In the case, how could we get only data triggered by periodical munual compaction?
On (23/02/28 14:20), Minchan Kim wrote: > On Sun, Feb 26, 2023 at 12:55:45PM +0900, Sergey Senozhatsky wrote: > > On (23/02/23 15:51), Minchan Kim wrote: > > > On Thu, Feb 23, 2023 at 12:04:50PM +0900, Sergey Senozhatsky wrote: > > > > Extend zsmalloc zs_pool_stats with a new member that > > > > holds the number of objects pool compaction moved > > > > between pool pages. > > > > > > I totally understand this new stat would be very useful for your > > > development but not sure it's really useful for workload tune or > > > monitoring. > > > > > > Unless we have strong usecase, I'd like to avoid new stat. > > > > The way I see is that it *can* give some interesting additional data to > > periodical compaction (the one is not triggeed by the shrinker): if the > > number of moves objects is relatively high but the number of comapcted > > (feeed) pages is relatively low then the system has fragmentation in > > small size classes (that tend to have many objects per zspage but not > > too many pages per zspage) and in this case the interval between > > periodical compactions probably can be increased. What do you think? > > In the case, how could we get only data triggered by periodical munual > compaction? Something very simple like read zram mm_stat trigger comapction read zram mm_stat can work in most cases, I guess. There can be memory pressure and shrinkers can compact the pool concurrently, in which case mm_stat will include shrinker impact, but that's probably not a problem. If system is under memory pressure then user space in general does not have to do comapction, since the kernel will handle it. Just an idea. It feels like "pages compacted" on its own tells very little, but I don't insist on exporting that new stat.
On Wed, Mar 01, 2023 at 12:54:56PM +0900, Sergey Senozhatsky wrote: > On (23/02/28 14:20), Minchan Kim wrote: > > On Sun, Feb 26, 2023 at 12:55:45PM +0900, Sergey Senozhatsky wrote: > > > On (23/02/23 15:51), Minchan Kim wrote: > > > > On Thu, Feb 23, 2023 at 12:04:50PM +0900, Sergey Senozhatsky wrote: > > > > > Extend zsmalloc zs_pool_stats with a new member that > > > > > holds the number of objects pool compaction moved > > > > > between pool pages. > > > > > > > > I totally understand this new stat would be very useful for your > > > > development but not sure it's really useful for workload tune or > > > > monitoring. > > > > > > > > Unless we have strong usecase, I'd like to avoid new stat. > > > > > > The way I see is that it *can* give some interesting additional data to > > > periodical compaction (the one is not triggeed by the shrinker): if the > > > number of moves objects is relatively high but the number of comapcted > > > (feeed) pages is relatively low then the system has fragmentation in > > > small size classes (that tend to have many objects per zspage but not > > > too many pages per zspage) and in this case the interval between > > > periodical compactions probably can be increased. What do you think? > > > > In the case, how could we get only data triggered by periodical munual > > compaction? > > Something very simple like > > read zram mm_stat > trigger comapction > read zram mm_stat > > can work in most cases, I guess. There can be memory pressure > and shrinkers can compact the pool concurrently, in which case > mm_stat will include shrinker impact, but that's probably not > a problem. If system is under memory pressure then user space Agreed. > in general does not have to do comapction, since the kernel will > handle it. > > Just an idea. It feels like "pages compacted" on its own tells very > little, but I don't insist on exporting that new stat. I don't mind adding the simple metric but I want to add metric if we have real usecase with handful of comments how they uses it in real world. Thanks.
On (23/03/01 15:48), Minchan Kim wrote: > > in general does not have to do comapction, since the kernel will > > handle it. > > > > Just an idea. It feels like "pages compacted" on its own tells very > > little, but I don't insist on exporting that new stat. > > I don't mind adding the simple metric but I want to add metric if > we have real usecase with handful of comments how they uses it > in real world. I'll drop it from the series for now.
diff --git a/include/linux/zsmalloc.h b/include/linux/zsmalloc.h index a48cd0ffe57d..8b3fa5b4a68c 100644 --- a/include/linux/zsmalloc.h +++ b/include/linux/zsmalloc.h @@ -36,6 +36,8 @@ enum zs_mapmode { struct zs_pool_stats { /* How many pages were migrated (freed) */ atomic_long_t pages_compacted; + /* How many objects were migrated during compaction */ + atomic_long_t objs_moved; }; struct zs_pool; diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index eacf9e32da5c..f7e69df48fb0 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -1815,6 +1815,7 @@ static void migrate_zspage(struct zs_pool *pool, struct size_class *class, obj_idx++; record_obj(handle, free_obj); obj_free(class->size, used_obj, NULL); + atomic_long_inc(&pool->stats.objs_moved); } /* Remember last position in this iteration */