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:31:32 +0900
From:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:	Minchan Kim <minchan@...nel.org>
Cc:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [PATCH 0/3] zsmalloc: small compaction improvements

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.

/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
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%).

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