[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150309004859.GB15184@blaptop>
Date: Mon, 9 Mar 2015 09:49:00 +0900
From: Minchan Kim <minchan@...nel.org>
To: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc: akpm@...ux-foundation.org, ddstreet@...e.org, gunho.lee@....com,
iamjoonsoo.kim@....com, jmarchan@...hat.com, juno.choi@....com,
mel@....ul.ie, ngupta@...are.org, semenzato@...gle.com,
sergey.senozhatsky@...il.com, sjennings@...iantweb.net,
mm-commits@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: + zram-support-compaction.patch added to -mm tree
Hello Sergey,
On Thu, Mar 05, 2015 at 02:29:42PM +0900, Sergey Senozhatsky wrote:
> On (03/04/15 14:02), akpm@...ux-foundation.org wrote:
> > +What: /sys/block/zram<id>/compact
> > +Date: August 2015
> > +Contact: Minchan Kim <minchan@...nel.org>
> > +Description:
> > + The compact file is write-only and trigger compaction for
> > + allocator zrm uses. The allocator moves some objects so that
> > + it could free fragment space.
> > +
> > +What: /sys/block/zram<id>/num_migrated
> > +Date: August 2015
> > +Contact: Minchan Kim <minchan@...nel.org>
> > +Description:
> > + The compact file is read-only and shows how many object
> > + migrated by compaction.
> > diff -puN drivers/block/zram/zram_drv.c~zram-support-compaction drivers/block/zram/zram_drv.c
> > --- a/drivers/block/zram/zram_drv.c~zram-support-compaction
> > +++ a/drivers/block/zram/zram_drv.c
> > @@ -70,6 +70,27 @@ static inline struct zram *dev_to_zram(s
> > return (struct zram *)dev_to_disk(dev)->private_data;
> > }
>
> First of all, my apologies to Andrew Morton. if I reply to this email, my mutt for
> some reason replaces akpm at linux-foundation.org with linux-kernel at vger.kernel.org
> (I can't see why this is happening, but this is somehow a `stable behaviour'). I didn't
> spot this, so this is why Andrew was not Cc-d to my previous reply to this eamil.
>
>
>
>
> rather a discussion question.
>
> Minchan, do you want to provide num_migrated as part of zsmalloc stats rather
> than having yet another zram attr? we already provide zsmalloc stats and this
> type of information seems to belong there. just idea.
Hmm, CONFIG_ZSMALLOC_STAT is actually to show zsmalloc internals. That's why
it is on debugfs. If we add the stat into zsmalloc, we should turn on debugfs
and CONFIG_ZSMALLOC_STAT to see *a* stat. Even, CONFIG_ZSMALLOC_STAT will add
unncessary overheads to account another stats fo zsmalloc internals.
As well, if we add auto-compacion like stuff in zsmalloc(ie, it will trigger
by itself if fragmention is over to predefined theshold), the stat will
accumulate stat while someone want to see snapshot compaction effiecieny
of the moment.
So, I want to keep it in zram now.
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists