linux-kernel - Re: [PATCH 0/3] zsmalloc: small compaction improvements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 14 Jul 2015 09:55:00 +0900
From:	Minchan Kim <minchan@...nel.org>
To:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] zsmalloc: small compaction improvements

On Tue, Jul 14, 2015 at 09:31:32AM +0900, Sergey Senozhatsky wrote:
> Hello Minchan,
> 
> On (07/14/15 08:36), Minchan Kim wrote:
> [..]
> > >       if [ `cat /sys/block/zram<id>/compact` -gt 10 ]; then
> > >           echo 1 > /sys/block/zram<id>/compact;
> > >       fi
> > > 
> > > Up until now user space could not tell whether compaction
> > > will result in any gain.
> > 
> > First of all, thanks for the looking this.
> > 
> > Question:
> > 
> > What is motivation?
> > IOW, did you see big overhead by user-triggered compaction? so,
> > do you want to throttle it by userspace?
> 
> It depends on 'big overhead' definition, of course. We don't care
> that much when compaction is issued by the shrinker, because things
> are getting bad and we can sacrifice performance. But user triggered
> compaction on a I/O pressured device can needlessly slow things down,
> especially now, when we drain ALMOST_FULL classes.

You mean performance overhead by additional alloc_pages?
If so, you mean ALMOST_EMPTY|ALMOST_FULL, not only ALMOST_FULL?

So, it's performance enhance patch?
Please give the some number to justify patchset.

> 
> /sys/block/zram<id>/compact is a black box. We provide it, we don't
> throttle it in the kernel, and user space is absolutely clueless when
> it invokes compaction. From some remote (or alternative) point of

But we have zs_can_compact so it can effectively skip the class if it
is not proper class.

> view compaction can be seen as "zsmalloc's cache flush" (unused objects
> make write path quicker - no zspage allocation needed) and it won't
> hurt to give user space some numbers so it can decide if the whole
> thing is worth it (that decision is, once again, I/O pattern and
> setup specific -- some users may be interested in compaction only
> if it will reduce zsmalloc's memory consumption by, say, 15%).

Again, your claim is performace so I need number.
If it's really horrible, I guess below interface makes user handy
without peeking nr_can_compact ad doing compact.

        /* Tell zram to compact if fragment ration is higher 15% */
        echo 15% > /sys/block/zram0/compact
        or
        echo 15% > /sys/block/zram/compact_condition

Anyway, we need a number before starting discussion.

Thanks.
> 
> 	-ss

-- 
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/