[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y2VPQlnEiP75mY5O@google.com>
Date: Fri, 4 Nov 2022 10:43:30 -0700
From: Minchan Kim <minchan@...nel.org>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Nitin Gupta <ngupta@...are.org>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCHv4 2/9] zram: Add recompression algorithm sysfs knob
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.
Powered by blists - more mailing lists