All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Yosry Ahmed <yosryahmed@google.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCHv2 5/6] zsmalloc: extend compaction statistics
Date: Wed, 1 Mar 2023 15:48:02 -0800	[thread overview]
Message-ID: <Y//kMuCV7dzdrfGp@google.com> (raw)
In-Reply-To: <Y/7MkLdVXImxPQeJ@google.com>

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.


  reply	other threads:[~2023-03-01 23:48 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-23  3:04 [PATCHv2 0/6] zsmalloc: fine-grained fullness and new compaction algorithm Sergey Senozhatsky
2023-02-23  3:04 ` [PATCHv2 1/6] zsmalloc: remove insert_zspage() ->inuse optimization Sergey Senozhatsky
2023-02-23 23:09   ` Minchan Kim
2023-02-26  4:40     ` Sergey Senozhatsky
2023-02-23  3:04 ` [PATCHv2 2/6] zsmalloc: remove stat and fullness enums Sergey Senozhatsky
2023-02-23 23:11   ` Minchan Kim
2023-02-23 23:32     ` Yosry Ahmed
2023-02-26  4:39     ` Sergey Senozhatsky
2023-02-23  3:04 ` [PATCHv2 3/6] zsmalloc: fine-grained inuse ratio based fullness grouping Sergey Senozhatsky
2023-02-23 23:27   ` Minchan Kim
2023-02-26  4:38     ` Sergey Senozhatsky
2023-02-28 22:53       ` Minchan Kim
2023-03-01  4:05         ` Sergey Senozhatsky
2023-03-02  0:13           ` Minchan Kim
2023-03-01  8:55         ` Sergey Senozhatsky
2023-03-02  0:28           ` Minchan Kim
2023-03-02  0:53             ` Sergey Senozhatsky
2023-03-03  0:20               ` Minchan Kim
2023-03-03  1:06                 ` Sergey Senozhatsky
2023-03-03  1:38                   ` Minchan Kim
2023-03-03  1:43                     ` Sergey Senozhatsky
2023-02-23  3:04 ` [PATCHv2 4/6] zsmalloc: rework compaction algorithm Sergey Senozhatsky
2023-02-23 23:46   ` Minchan Kim
2023-02-26  4:09     ` Sergey Senozhatsky
2023-02-28 23:14   ` Minchan Kim
2023-03-01  3:47     ` Sergey Senozhatsky
2023-02-23  3:04 ` [PATCHv2 5/6] zsmalloc: extend compaction statistics Sergey Senozhatsky
2023-02-23 23:51   ` Minchan Kim
2023-02-26  3:55     ` Sergey Senozhatsky
2023-02-28 22:20       ` Minchan Kim
2023-03-01  3:54         ` Sergey Senozhatsky
2023-03-01 23:48           ` Minchan Kim [this message]
2023-03-03  1:57             ` Sergey Senozhatsky
2023-02-23  3:04 ` [PATCHv2 6/6] zram: show zsmalloc objs_moved stat in mm_stat Sergey Senozhatsky
2023-02-23 23:53 ` [PATCHv2 0/6] zsmalloc: fine-grained fullness and new compaction algorithm Minchan Kim
2023-02-26  3:50   ` Sergey Senozhatsky
2023-02-28 22:17     ` Minchan Kim
2023-03-01  3:57       ` Sergey Senozhatsky
2023-03-01 23:48         ` Minchan Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y//kMuCV7dzdrfGp@google.com \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=senozhatsky@chromium.org \
    --cc=yosryahmed@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.