linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Nitin Gupta <ngupta@vflare.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCHv4 2/9] zram: Add recompression algorithm sysfs knob
Date: Fri, 4 Nov 2022 10:43:30 -0700	[thread overview]
Message-ID: <Y2VPQlnEiP75mY5O@google.com> (raw)
In-Reply-To: <Y2Sat1/FCCT0Lia/@google.com>

On Fri, Nov 04, 2022 at 01:53:11PM +0900, Sergey Senozhatsky wrote:
> On (22/11/04 12:18), Sergey Senozhatsky wrote:
> > On (22/11/03 09:34), Minchan Kim wrote:
> > > Yeah, I like the name and priority format.
> > > 
> > > Only question is how we could support algorithm selection change
> > > under considering multiple secondary algorithms.
> > 
> > So what I was thinking about, and I'm still in the mental model that
> > re-compression is a user-space event, just like writeback, extension
> > of recompress sysfs knob with "algo_index" (or something similar) which
> > will mirror algorithm priority.
> > 
> > Example:
> > 
> > Configure 2 alternative algos, with priority 1 and 2
> > 
> > 	echo "name=lz4 priority=1" > recomp_algo
> > 	echo "name=lz5 priority=2" > recomp_algo
> > 
> > Recompress pages using algo 1 and algo 2
> > 
> > 	echo "type=huge threshold=3000 algo_idx=1" > recompress
> > 	echo "type=idle threshold=2000 algo_idx=2" > recompress
> > 
> > Maybe we can even pass algo name instead of idx.
> 
> Or pass priority= so that interface that uses algorithms has the
> same keyword that the interface that configures those algorithms.

Hmm, why do we need algo_idx here if we already set up every
fields at algorithm setup time?

My understaind(assuming default(i.e., primary) algo is lzo) is

    echo "name=lz4 priority=1" > recomp_algo
    echo "name=lz5 priority=2" > recomp_algo

    echo "type=huge threshold=3000" > recompress

It will try compress every objects which greater than 3000B with lz4 first
and then lz5 if it's stillgreater or equal than 3000(or same size class).

> 
> I still don't see many use-cases for "delete algorithm", to be honest.
> ZRAM is configured by scripts in 99.99999% of cases and it is

For the development time in the local side, people usually type in
until they will have solid script version. If we asks resetting
to zram to modify it, it's not good and consistent with other
sysfs knobs we could overwrite it to change it. How about supporting
overwritting to chage it over priority?

    echo "name=lz4 priority=1" > recomp_algo
    echo "name=lz5 priority=2" > recomp_algo

    # or I realized to change lz5 to lz7 so
    echo "name=lz6 priority=2" > recomp_algo

> quite static once it has been configured. So we probably can use
> the "don't setup algorithms that you don't need" approach, to keep
> things simpler.

  reply	other threads:[~2022-11-04 17:44 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-18  4:55 [PATCHv4 0/9] zram: Support multiple compression streams Sergey Senozhatsky
2022-10-18  4:55 ` [PATCHv4 1/9] zram: Preparation for multi-zcomp support Sergey Senozhatsky
2022-11-02 20:13   ` Minchan Kim
2022-11-03  2:40     ` Sergey Senozhatsky
2022-10-18  4:55 ` [PATCHv4 2/9] zram: Add recompression algorithm sysfs knob Sergey Senozhatsky
2022-11-02 20:15   ` Minchan Kim
2022-11-03  3:05     ` Sergey Senozhatsky
2022-11-03  3:54       ` Sergey Senozhatsky
2022-11-03 17:10         ` Minchan Kim
2022-11-03  4:09       ` Sergey Senozhatsky
2022-11-03  5:36         ` Sergey Senozhatsky
2022-11-03 17:11         ` Minchan Kim
2022-11-03 16:34       ` Minchan Kim
2022-11-04  3:18         ` Sergey Senozhatsky
2022-11-04  4:53           ` Sergey Senozhatsky
2022-11-04 17:43             ` Minchan Kim [this message]
2022-11-04 23:41               ` Sergey Senozhatsky
2022-11-05  0:00                 ` Sergey Senozhatsky
2022-11-07 19:08                   ` Minchan Kim
2022-11-08  0:40                     ` Sergey Senozhatsky
2022-11-05  0:01                 ` Minchan Kim
2022-11-05  1:30                   ` Sergey Senozhatsky
2022-11-04 16:34           ` Minchan Kim
2022-11-04 23:25             ` Sergey Senozhatsky
2022-11-04 23:40               ` Minchan Kim
2022-11-04 23:44                 ` Sergey Senozhatsky
2022-11-05  0:02                   ` Minchan Kim
2022-10-18  4:55 ` [PATCHv4 3/9] zram: Factor out WB and non-WB zram read functions Sergey Senozhatsky
2022-11-02 20:20   ` Minchan Kim
2022-11-03  2:43     ` Sergey Senozhatsky
2022-10-18  4:55 ` [PATCHv4 4/9] zram: Introduce recompress sysfs knob Sergey Senozhatsky
2022-11-02 21:06   ` Minchan Kim
2022-11-03  3:25     ` Sergey Senozhatsky
2022-11-03  6:03       ` Sergey Senozhatsky
2022-11-03 17:00       ` Minchan Kim
2022-11-04  3:48         ` Sergey Senozhatsky
2022-11-04  7:12           ` Sergey Senozhatsky
2022-11-04 17:53             ` Minchan Kim
2022-11-04 17:27           ` Minchan Kim
2022-11-04 23:22             ` Sergey Senozhatsky
2022-11-04  7:53         ` Sergey Senozhatsky
2022-11-04  8:08           ` Sergey Senozhatsky
2022-11-04 17:47           ` Minchan Kim
2022-10-18  4:55 ` [PATCHv4 5/9] documentation: Add recompression documentation Sergey Senozhatsky
2022-10-18  4:55 ` [PATCHv4 6/9] zram: Add recompression algorithm choice to Kconfig Sergey Senozhatsky
2022-10-18  4:55 ` [PATCHv4 7/9] zram: Add recompress flag to read_block_state() Sergey Senozhatsky
2022-10-18  4:55 ` [PATCHv4 8/9] zram: Clarify writeback_store() comment Sergey Senozhatsky
2022-10-18  4:55 ` [PATCHv4 9/9] zram: Use IS_ERR_VALUE() to check for zs_malloc() errors Sergey Senozhatsky
2022-11-02 20:07 ` [PATCHv4 0/9] zram: Support multiple compression streams Minchan Kim
2022-11-03  3:36   ` Sergey Senozhatsky

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=Y2VPQlnEiP75mY5O@google.com \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ngupta@vflare.org \
    --cc=senozhatsky@chromium.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).