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 BEB6BC64EC7 for ; Wed, 1 Mar 2023 03:55:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 207B76B0095; Tue, 28 Feb 2023 22:55:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B7C76B0096; Tue, 28 Feb 2023 22:55:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 080926B0098; Tue, 28 Feb 2023 22:55:04 -0500 (EST) 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 ED90C6B0095 for ; Tue, 28 Feb 2023 22:55:03 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C44F380FFB for ; Wed, 1 Mar 2023 03:55:03 +0000 (UTC) X-FDA: 80518963686.11.7B45715 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by imf03.hostedemail.com (Postfix) with ESMTP id EC5562000A for ; Wed, 1 Mar 2023 03:55:01 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="c0J1/NU4"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf03.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.169 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677642902; 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=dxXNGS30xbDsiSrnP4eiOcS4VTFoXH2EtjdLkfq37fw=; b=4+jye2uHYNak1T6ULs6jKNtRThYTD6FmTcxWxpo68IhMuXOJb6HQ9wNRalrQJP3qfw9JCB wBGOL9Era6xLTgWssOlFd+O/a3Vuj7WV1zvPl503tDMucqWz+ZsLCAG4c9JViQrDWLImne bli61Cdjbgye/DiilkwWfsQAQP1iQOo= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="c0J1/NU4"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf03.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.169 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677642902; a=rsa-sha256; cv=none; b=oumekqc3UdW6K9Lkwc4KjevKibffKcx1LkPW+5dp8YOzIoDL3oukYs+kv1BIcl++rd9x9j 0dRjrcg3iEjcrI3G18JVPD6/0zZHP0desuNaikOHPpQl4qRV0olg2dy1FI4/hDjpQ8B1VA +i3bLipKRg35V18lnO3IOvvZPDNIMJQ= Received: by mail-pl1-f169.google.com with SMTP id u5so9267757plq.7 for ; Tue, 28 Feb 2023 19:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; 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=dxXNGS30xbDsiSrnP4eiOcS4VTFoXH2EtjdLkfq37fw=; b=c0J1/NU4C1p2MxCz+gBaYYJQLAZIuLePvgiforWM9hGguJNr9GIviOO9PFuqkkokPd TJ7QXLyslj1N5fnbffE+++FDraYmb1b0KZTWP7zizhSI/8D7zrvVOMaihPQaDme6X1ZO yudS0mLC3ejuw0EHp9HOdbryGX8ioDq0SDuxU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=dxXNGS30xbDsiSrnP4eiOcS4VTFoXH2EtjdLkfq37fw=; b=3rU96DvbZ8PVGJep9l2gCZ6PqZ+73/5e3i6dcbhubaEPh0FkUOH1dIREvqneDNaST9 dqGyYFZaBxROicpYSDLthLoFofxz5TjjBWx2A+tl9wqVkglGTqbYw24jAhAdV9h2bX+q VrDhmpaAFmug1wb0mL8mjFIpPCp4YoRgtvgpya43KWaUYgoQeqAHPhOPXUMw0NYFTPIQ 004oqBbdb1DFge6sFgpim5f5FtBXtzs8AwMvpgYyny1l+d1Oaj1ucyl6CXUK14ZaEQ/Z KTx58WoBhpQU+27Xfh/UoifeflEC2LrjoHxAhJV2EeYuL1/1QHipenWbl5w2OBtj25z0 4EIg== X-Gm-Message-State: AO0yUKXya2gfTVSUhRe6h4hMYt69iOsz4Fo5oEU5/FD097neBeXAwNfS +jo0CvZFot3SqoaJyB8ow5w3ng== X-Google-Smtp-Source: AK7set/dibQGpnJXukAG07B/Aq07DluLOU8RyRB+i3Rlm4VMIo7dGNQeNpqZXMGsHs/9/SRKKVfVhA== X-Received: by 2002:a05:6a20:8f04:b0:cc:9ca2:8b5f with SMTP id b4-20020a056a208f0400b000cc9ca28b5fmr6830196pzk.15.1677642900774; Tue, 28 Feb 2023 19:55:00 -0800 (PST) Received: from google.com (KD124209188001.ppp-bb.dion.ne.jp. [124.209.188.1]) by smtp.gmail.com with ESMTPSA id d9-20020aa78689000000b005898fcb7c1bsm7000864pfo.177.2023.02.28.19.54.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Feb 2023 19:55:00 -0800 (PST) Date: Wed, 1 Mar 2023 12:54:56 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , Andrew Morton , Yosry Ahmed , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv2 5/6] zsmalloc: extend compaction statistics Message-ID: References: <20230223030451.543162-1-senozhatsky@chromium.org> <20230223030451.543162-6-senozhatsky@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: EC5562000A X-Stat-Signature: kcd4tpssq8bp63kxdifppfo6dwz8awk9 X-HE-Tag: 1677642901-844834 X-HE-Meta: U2FsdGVkX1/5/xSZ3sivQUY5Tvvej0EB84WlRl0tAF5LtHPttwXpPJK8GlMN0Pnms0AbRpUMy6A92Jv293WhtLDr17rgnQ59/VkGk9jIe39wIXRtvE7dUgHUkPsaObK5iPhNWB0Jvl2iIOU12GbUBqmAsirq2/ZySjDHgiaY+37RkA5d/nHyi0jTC4EByPPFZpVWMyUN8U+9nmAWCv8Jfiu7ufuUyKDYQxhyWcCT4TPpN+m/yyzBG7gcEUTAHicoQ0M0DsEl8w4YvraAILVjs6tD43orEGJkiP3Gl0UnFWHl2dMZyKPO8nlxaL+MaiIXuc8lhc0CxwowQIdCSS3XupLhwZp7UHHLgn6aDXJLlemoWpDeql9Q/9kJK7cQuE61GigAd9JD7OkFCt0biI1oT1bC80j1NqXzVrkNJQg+InAfKS58Hfx0jY0BUnpNjhCUsBBoiguZF3CA0xdnMofVT2P/sqiwkecv599bEWwinUa/qPzDUrOeSwpL5EIi0qtx4KKeEaz5rkdWzWjifIjwtSN89ZEwjiMI6u8R4FjxmwKit6wbxxyqiVma0zXQnI4MsGZRYOHrusUwo+Axg+JxdwmRqFE0cX2SIhLTkLn8SDc4lRFgBhXPP2zH5zWgSHR2N7G6NEZZdDgdeFZ6iNxRHN0AJ+pIH8nwKgMR2U0a1h5ZozyKQF1X9QuoQUFq/mEW4A5TnbgrytcYRjph9qyyt9sZb/n7MfQA04G9YbJZikqw6mPDJTM4OgNwpP6mNf+HRjhNiufSLiJJmZYrCip+HfHyfRL8A50qpgqPHd/hQEOXs8mpPdFCzSKXC9/ALbbD3OhoD6RrGrZi/cZZMlyc28zpVKmsnCKV5085EtMrAyXtcQ2u56Gc2E7AvHBPiIr6Ir2Wtv5OVAKaNiXKdPVfki0l1zQ/47KvLhSPZeHGDLCK5fq0ZGVKxpuBbNVVQTh+Ms+4GSnuKsM7RZO5bbQ moj+sdQJ 4f0etvaWiMUXekaKXk8DwTu/m/Kp5TVzXHqL4pSQ3qYNBfLGzGgr/xnl3v8iDOWWnwAJh+tKPdXl3C2FqiarYywlEKu3jg5VTk1AnUR3PkUj+oGdP/HFp2zfPWYwHePY2rr0RPIyUi3mURwT78w3RrI7HjZIsB35N8VW9EJzUFKtB7ZF9ynDId9MPJfo8IVWPtOtO9vYy6zNr347C2smH/kyxlKjTsFMTMU8i5XSF7ob9+si/ntNHkWzfCyZwCEMBClRhnZVaEMT8YbeaB9JEczE8gef0VBLkjT/hNy4g45w0OE2ZXLN/be87rWeoC/qpEnHt1pPZLyGupdk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.057917, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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.