The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7deddb00d1315fcb47c8da59ad4a9b9a03cda1f2

commit 7deddb00d1315fcb47c8da59ad4a9b9a03cda1f2
Author: Minchan Kim <minchan@kernel.org>
Date: Wed Feb 08 04:13:49 2017

UPSTREAM: zsmalloc: remove unnecessary insertion/removal of zspage in compaction

In putback_zspage, we don't need to insert a zspage into list of zspage
in size_class again to just fix fullness group. We could do directly
without reinsertion so we could save some instuctions.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I97355f95ba17c5664effa0b350ab0a3c29c6fed7
Reported-by: Heesub Shin <heesub.shin@samsung.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Ganesh Mahendran <opensource.ganesh@gmail.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Juneho Choi <juno.choi@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 839373e645d12613308d9148041c4bd967bce8d5)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416586
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/7deddb00d1315fcb47c8da59ad4a9b9a03cda1f2/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1b9fd0b3e8734229938f4b9a1119b7177065ec47

commit 1b9fd0b3e8734229938f4b9a1119b7177065ec47
Author: Heesub Shin <heesub.shin@samsung.com>
Date: Wed Feb 08 04:13:50 2017

UPSTREAM: zsmalloc: fix fatal corruption due to wrong size class selection

There is no point in overriding the size class below.  It causes fatal
corruption on the next chunk on the 3264-bytes size class, which is the
last size class that is not huge.

For example, if the requested size was exactly 3264 bytes, current
zsmalloc allocates and returns a chunk from the size class of 3264 bytes,
not 4096.  User access to this chunk may overwrite head of the next
adjacent chunk.

Here is the panic log captured when freelist was corrupted due to this:

    Kernel BUG at ffffffc00030659c [verbose debug info unavailable]
    Internal error: Oops - BUG: 96000006 [#1] PREEMPT SMP
    Modules linked in:
    exynos-snapshot: core register saved(CPU:5)
    CPUMERRSR: 0000000000000000, L2MERRSR: 0000000000000000
    exynos-snapshot: context saved(CPU:5)
    exynos-snapshot: item - log_kevents is disabled
    CPU: 5 PID: 898 Comm: kswapd0 Not tainted 3.10.61-4497415-eng #1
    task: ffffffc0b8783d80 ti: ffffffc0b71e8000 task.ti: ffffffc0b71e8000
    PC is at obj_idx_to_offset+0x0/0x1c
    LR is at obj_malloc+0x44/0xe8
    pc : [<ffffffc00030659c>] lr : [<ffffffc000306604>] pstate: a0000045
    sp : ffffffc0b71eb790
    x29: ffffffc0b71eb790 x28: ffffffc00204c000
    x27: 000000000001d96f x26: 0000000000000000
    x25: ffffffc098cc3500 x24: ffffffc0a13f2810
    x23: ffffffc098cc3501 x22: ffffffc0a13f2800
    x21: 000011e1a02006e3 x20: ffffffc0a13f2800
    x19: ffffffbc02a7e000 x18: 0000000000000000
    x17: 0000000000000000 x16: 0000000000000feb
    x15: 0000000000000000 x14: 00000000a01003e3
    x13: 0000000000000020 x12: fffffffffffffff0
    x11: ffffffc08b264000 x10: 00000000e3a01004
    x9 : ffffffc08b263fea x8 : ffffffc0b1e611c0
    x7 : ffffffc000307d24 x6 : 0000000000000000
    x5 : 0000000000000038 x4 : 000000000000011e
    x3 : ffffffbc00003e90 x2 : 0000000000000cc0
    x1 : 00000000d0100371 x0 : ffffffbc00003e90

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ia29414b1867e37fd927f4dfd3e8fbc7e6b5f646f
Reported-by: Sooyong Suk <s.suk@samsung.com>
Signed-off-by: Heesub Shin <heesub.shin@samsung.com>
Tested-by: Sooyong Suk <s.suk@samsung.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 81da9b13f73653bf5f38c63af8029fc459198ac0)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416587
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/1b9fd0b3e8734229938f4b9a1119b7177065ec47/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7ad91d4c357ce4d851ddb17f14e307c8e5f0c2c4

commit 7ad91d4c357ce4d851ddb17f14e307c8e5f0c2c4
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 04:13:51 2017

UPSTREAM: zsmalloc: remove extra cond_resched() in __zs_compact

Do not perform cond_resched() before the busy compaction loop in
__zs_compact(), because this loop does it when needed.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ic8f19ffae486a356300cc28fe3d86fdba87d29dc
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 160a117f0864871ae1bab26554a985a1d2861afd)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416588
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/7ad91d4c357ce4d851ddb17f14e307c8e5f0c2c4/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7415aca32c382d505b19dcd10cb601008d87ed86

commit 7415aca32c382d505b19dcd10cb601008d87ed86
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 04:13:52 2017

UPSTREAM: zsmalloc: fix a null pointer dereference in destroy_handle_cache()

If zs_create_pool()->create_handle_cache()->kmem_cache_create() or
pool->name allocation fails, zs_create_pool()->destroy_handle_cache()
will dereference the NULL pool->handle_cachep.

Modify destroy_handle_cache() to avoid this.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: If2937898124ddca026b9e4106d3d33b5175af5af
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 02f7b4145da113683ad64c74bf64605e16b71789)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416589
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/7415aca32c382d505b19dcd10cb601008d87ed86/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0b36a78181a72ee2fa306ad999fc5a8e1ffc7fbb

commit 0b36a78181a72ee2fa306ad999fc5a8e1ffc7fbb
Author: Marcin Jabrzyk <m.jabrzyk@samsung.com>
Date: Wed Feb 08 04:13:53 2017

UPSTREAM: zsmalloc: remove obsolete ZSMALLOC_DEBUG

The DEBUG define in zsmalloc is useless, there is no usage of it at all.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ia4450f062beb1644b578961eca9de25d673c456e
Signed-off-by: Marcin Jabrzyk <m.jabrzyk@samsung.com>
Acked-by: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 13a18a1c04775e48788a25ba7ed17c885df6b1d1)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416590
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/0b36a78181a72ee2fa306ad999fc5a8e1ffc7fbb/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4076e2ac5ad147d197ce20d9df3c30840250427b

commit 4076e2ac5ad147d197ce20d9df3c30840250427b
Author: Dan Streetman <ddstreet@ieee.org>
Date: Wed Feb 08 15:26:31 2017

UPSTREAM: zpool: remove zpool_evict()

Remove zpool_evict() helper function.  As zbud is currently the only
zpool implementation that supports eviction, add zpool and zpool_ops
references to struct zbud_pool and directly call zpool_ops->evict(zpool,
handle) on eviction.

Currently zpool provides the zpool_evict helper which locks the zpool
list lock and searches through all pools to find the specific one
matching the caller, and call the corresponding zpool_ops->evict
function.  However, this is unnecessary, as the zbud pool can simply
keep a reference to the zpool that created it, as well as the zpool_ops,
and directly call the zpool_ops->evict function, when it needs to evict
a page.  This avoids a spinlock and list search in zpool for each
eviction.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Iceb78f011f8ed511cb2b514ba1f1be27be4cc8a9
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 479305fd7172503772575997eb6f1b0a2bb4a107)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416591
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/4076e2ac5ad147d197ce20d9df3c30840250427b/mm/zsmalloc.c
[modify] https://crrev.com/4076e2ac5ad147d197ce20d9df3c30840250427b/mm/zpool.c
[modify] https://crrev.com/4076e2ac5ad147d197ce20d9df3c30840250427b/include/linux/zpool.h
[modify] https://crrev.com/4076e2ac5ad147d197ce20d9df3c30840250427b/mm/zbud.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/84a86d1960a4774c24c2103f45de78056e1270fc

commit 84a86d1960a4774c24c2103f45de78056e1270fc
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Wed Feb 08 15:26:32 2017

UPSTREAM: mm: zpool: constify the zpool_ops

The structure zpool_ops is not modified so make the pointer to it a
pointer to const.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ibdf5669307313396dd14621aefef776d971e486a
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 786727799a85aeabc20cab5ecfb72771bcbd6b85)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416592
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/84a86d1960a4774c24c2103f45de78056e1270fc/mm/zsmalloc.c
[modify] https://crrev.com/84a86d1960a4774c24c2103f45de78056e1270fc/mm/zpool.c
[modify] https://crrev.com/84a86d1960a4774c24c2103f45de78056e1270fc/include/linux/zpool.h
[modify] https://crrev.com/84a86d1960a4774c24c2103f45de78056e1270fc/mm/zbud.c
[modify] https://crrev.com/84a86d1960a4774c24c2103f45de78056e1270fc/mm/zswap.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/08b2498f693fc4eca86fdccff29553e13d48821a

commit 08b2498f693fc4eca86fdccff29553e13d48821a
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Wed Feb 08 15:26:33 2017

UPSTREAM: mm: zbud: constify the zbud_ops

The structure zbud_ops is not modified so make the pointer to it a
pointer to const.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I8461b34b37ef2839de6bc23bd12ca54214fa89e8
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Acked-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit c83db4f419e7105af38cdcca80cc51213214a2c8)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416593
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/08b2498f693fc4eca86fdccff29553e13d48821a/mm/zbud.c
[modify] https://crrev.com/08b2498f693fc4eca86fdccff29553e13d48821a/include/linux/zbud.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/3b4ddc4bbcf86a95eaaa00ccc49c98dbaff428a9

commit 3b4ddc4bbcf86a95eaaa00ccc49c98dbaff428a9
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:26:34 2017

UPSTREAM: zsmalloc: drop unused variable `nr_to_migrate'

This patchset tweaks compaction and makes it possible to trigger pool
compaction automatically when system is getting low on memory.

zsmalloc in some cases can suffer from a notable fragmentation and
compaction can release some considerable amount of memory.  The problem
here is that currently we fully rely on user space to perform compaction
when needed.  However, performing zsmalloc compaction is not always an
obvious thing to do.  For example, suppose we have a `idle' fragmented
(compaction was never performed) zram device and system is getting low
on memory due to some 3rd party user processes (gcc LTO, or firefox,
etc.).  It's quite unlikely that user space will issue zpool compaction
in this case.  Besides, user space cannot tell for sure how badly pool
is fragmented; however, this info is known to zsmalloc and, hence, to a
shrinker.

This patch (of 7):

__zs_compact() does not use `nr_to_migrate', drop it.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: If848e94ff172d48727ee60b9d40ff25ebbc8040e
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit b430d1fd6c7d22cc07e7c22a2ee1078667605313)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416594
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/3b4ddc4bbcf86a95eaaa00ccc49c98dbaff428a9/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/66a54d66656a4ac564fad40550d554da28d7925a

commit 66a54d66656a4ac564fad40550d554da28d7925a
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:26:35 2017

UPSTREAM: zsmalloc: always keep per-class stats

Always account per-class `zs_size_stat' stats.  This data will help us
make better decisions during compaction.  We are especially interested
in OBJ_ALLOCATED and OBJ_USED, which can tell us if class compaction
will result in any memory gain.

For instance, we know the number of allocated objects in the class, the
number of objects being used (so we also know how many objects are not
used) and the number of objects per-page.  So we can ensure if we have
enough unused objects to form at least one ZS_EMPTY zspage during
compaction.

We calculate this value on per-class basis so we can calculate a total
number of zspages that can be released.  Which is exactly what a
shrinker wants to know.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: If8eb36b41b0bf2313652bec61b389f10a7bed504
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 57244594195fe697f9261c7970ca25db35280967)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416595
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/66a54d66656a4ac564fad40550d554da28d7925a/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/d785b739157c20b2ecc6b79c33d50c0d7f29253f

commit d785b739157c20b2ecc6b79c33d50c0d7f29253f
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:26:36 2017

UPSTREAM: zsmalloc: introduce zs_can_compact() function

This function checks if class compaction will free any pages.
Rephrasing -- do we have enough unused objects to form at least one
ZS_EMPTY page and free it.  It aborts compaction if class compaction
will not result in any (further) savings.

EXAMPLE (this debug output is not part of this patch set):

 - class size
 - number of allocated objects
 - number of used objects
 - max objects per zspage
 - pages per zspage
 - estimated number of pages that will be freed

[..]
class-512 objs:544 inuse:540 maxobj-per-zspage:8  pages-per-zspage:1 zspages-to-free:0
 ... class-512 compaction is useless. break
class-496 objs:660 inuse:570 maxobj-per-zspage:33 pages-per-zspage:4 zspages-to-free:2
class-496 objs:627 inuse:570 maxobj-per-zspage:33 pages-per-zspage:4 zspages-to-free:1
class-496 objs:594 inuse:570 maxobj-per-zspage:33 pages-per-zspage:4 zspages-to-free:0
 ... class-496 compaction is useless. break
class-448 objs:657 inuse:617 maxobj-per-zspage:9  pages-per-zspage:1 zspages-to-free:4
class-448 objs:648 inuse:617 maxobj-per-zspage:9  pages-per-zspage:1 zspages-to-free:3
class-448 objs:639 inuse:617 maxobj-per-zspage:9  pages-per-zspage:1 zspages-to-free:2
class-448 objs:630 inuse:617 maxobj-per-zspage:9  pages-per-zspage:1 zspages-to-free:1
class-448 objs:621 inuse:617 maxobj-per-zspage:9  pages-per-zspage:1 zspages-to-free:0
 ... class-448 compaction is useless. break
class-432 objs:728 inuse:685 maxobj-per-zspage:28 pages-per-zspage:3 zspages-to-free:1
class-432 objs:700 inuse:685 maxobj-per-zspage:28 pages-per-zspage:3 zspages-to-free:0
 ... class-432 compaction is useless. break
class-416 objs:819 inuse:705 maxobj-per-zspage:39 pages-per-zspage:4 zspages-to-free:2
class-416 objs:780 inuse:705 maxobj-per-zspage:39 pages-per-zspage:4 zspages-to-free:1
class-416 objs:741 inuse:705 maxobj-per-zspage:39 pages-per-zspage:4 zspages-to-free:0
 ... class-416 compaction is useless. break
class-400 objs:690 inuse:674 maxobj-per-zspage:10 pages-per-zspage:1 zspages-to-free:1
class-400 objs:680 inuse:674 maxobj-per-zspage:10 pages-per-zspage:1 zspages-to-free:0
 ... class-400 compaction is useless. break
class-384 objs:736 inuse:709 maxobj-per-zspage:32 pages-per-zspage:3 zspages-to-free:0
 ... class-384 compaction is useless. break
[..]

Every "compaction is useless" indicates that we saved CPU cycles.

class-512 has
	544	object allocated
	540	objects used
	8	objects per-page

Even if we have a ALMOST_EMPTY zspage, we still don't have enough room to
migrate all of its objects and free this zspage; so compaction will not
make a lot of sense, it's better to just leave it as is.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I2aa0ffa4b1158ced702ffd77ad5e5f7d63821821
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 04f05909e0fde36ba481ad4c850b666ebef1ac55)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416596
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/d785b739157c20b2ecc6b79c33d50c0d7f29253f/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6e08d8bc04d8820ed871af9b2c372c98e7745389

commit 6e08d8bc04d8820ed871af9b2c372c98e7745389
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:26:37 2017

UPSTREAM: zsmalloc: cosmetic compaction code adjustments

Change zs_object_copy() argument order to be (DST, SRC) rather than
(SRC, DST).  copy/move functions usually have (to, from) arguments
order.

Rename alloc_target_page() to isolate_target_page().  This function
doesn't allocate anything, it isolates target page, pretty much like
isolate_source_page().

Tweak __zs_compact() comment.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: If6cfb4e7a1515ec534b8c52c61440ca5d0d5e623
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 0dc63d488a2a433a4a85d3908b3f195c4e6450d2)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416597
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/6e08d8bc04d8820ed871af9b2c372c98e7745389/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7ee92f38853f15ac0a408a6ed0e0834f628e411d

commit 7ee92f38853f15ac0a408a6ed0e0834f628e411d
Author: karam.lee <karam.lee@lge.com>
Date: Wed Feb 08 15:26:38 2017

UPSTREAM: zram: remove bio parameter from zram_bvec_rw()

Recently rw_page block device operation has been added.  This patchset
implements rw_page operation for zram block device and does some clean-up.

This patch (of 3):

Remove an unnecessary parameter(bio) from zram_bvec_rw() and
zram_bvec_read().  zram_bvec_read() doesn't use a bio parameter, so remove
it.  zram_bvec_rw() calls a read/write operation not using bio, so a rw
parameter replaces a bio parameter.

BUG=chromium:670864
TEST=build elm

Signed-off-by: karam.lee <karam.lee@lge.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Acked-by: Jerome Marchand <jmarchan@redhat.com>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: <seungho1.park@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry-picked from commit b627cff3d308d3ccb3ec73a89260f5c7872e46a4)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>

Change-Id: Ib8064d6ae1fe43d1401acadfce90b1c542eb4fb7
Reviewed-on: https://chromium-review.googlesource.com/416598
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>

[modify] https://crrev.com/7ee92f38853f15ac0a408a6ed0e0834f628e411d/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/850bc1963a6fe1501d5259b2d3d3e0d7a760c8e5

commit 850bc1963a6fe1501d5259b2d3d3e0d7a760c8e5
Author: karam.lee <karam.lee@lge.com>
Date: Wed Feb 08 15:26:40 2017

UPSTREAM: zram: change parameter from vaild_io_request()

This patch changes parameter of valid_io_request for common usage.  The
purpose of valid_io_request() is to determine if bio request is valid or
not.

This patch use I/O start address and size instead of a BIO parameter for
common usage.

BUG=chromium:670864
TEST=build elm

Signed-off-by: karam.lee <karam.lee@lge.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Acked-by: Jerome Marchand <jmarchan@redhat.com>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: <seungho1.park@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry-picked from commit 54850e73e86e3bc092680d1bdb84eb322f982ab1)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>

Change-Id: I0a305fefd779ea4d316fa133703effd3c3b6528e
Reviewed-on: https://chromium-review.googlesource.com/416599
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>

[modify] https://crrev.com/850bc1963a6fe1501d5259b2d3d3e0d7a760c8e5/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0069fd95d1e6c560044961b817b154776e434b95

commit 0069fd95d1e6c560044961b817b154776e434b95
Author: karam.lee <karam.lee@lge.com>
Date: Wed Feb 08 15:26:41 2017

BACKPORT: zram: implement rw_page operation of zram

This patch implements rw_page operation for zram block device.

I implemented the feature in zram and tested it.  Test bed was the G2, LG
electronic mobile device, whtich has msm8974 processor and 2GB memory.

With a memory allocation test program consuming memory, the system
generates swap.

Operating time of swap_write_page() was measured.

--------------------------------------------------
|             |   operating time   | improvement |
|             |  (20 runs average) |             |
--------------------------------------------------
|with patch   |    1061.15 us      |    +2.4%    |
--------------------------------------------------
|without patch|    1087.35 us      |             |
--------------------------------------------------

Each test(with paged_io,with BIO) result set shows normal distribution and
has equal variance.  I mean the two values are valid result to compare.  I
can say operation with paged I/O(without BIO) is faster 2.4% with
confidence level 95%.

BUG=chromium:670864
TEST=build elm

[minchan@kernel.org: make rw_page opeartion return 0]
[minchan@kernel.org: rely on the bi_end_io for zram_rw_page fails]
[sergey.senozhatsky@gmail.com: code cleanup]
[minchan@kernel.org: add comment]
Signed-off-by: karam.lee <karam.lee@lge.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Acked-by: Jerome Marchand <jmarchan@redhat.com>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: <seungho1.park@lge.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 8c7f01025f7becd577bed9af93f974fc6798c5a3)
[SR: fix up conflict with CHROMIUM: Restrict swapon() to "zram"
 devices / lock down zram]
 Conflicts:
	drivers/block/zram/zram_drv.c
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>

Change-Id: Id1e7cb08d26ecc159f7e80e013f43198d54ab879
Reviewed-on: https://chromium-review.googlesource.com/416600
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>

[modify] https://crrev.com/0069fd95d1e6c560044961b817b154776e434b95/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1f2d0a4e456c29393efc028cc853616a49cba943

commit 1f2d0a4e456c29393efc028cc853616a49cba943
Author: Mahendran Ganesh <opensource.ganesh@gmail.com>
Date: Wed Feb 08 15:26:42 2017

UPSTREAM: mm/zram: correct ZRAM_ZERO flag bit position

In struct zram_table_entry, the element *value* contains obj size and obj
zram flags.  Bit 0 to bit (ZRAM_FLAG_SHIFT - 1) represent obj size, and
bit ZRAM_FLAG_SHIFT to the highest bit of unsigned long represent obj
zram_flags.  So the first zram flag(ZRAM_ZERO) should be from
ZRAM_FLAG_SHIFT instead of (ZRAM_FLAG_SHIFT + 1).

This patch fixes this cosmetic issue.

Also fix a typo, "page in now accessed" -> "page is now accessed"

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I4d8bef786b4335e099634100ad74af741782f9ed
Signed-off-by: Mahendran Ganesh <opensource.ganesh@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Acked-by: Weijie Yang <weijie.yang@samsung.com>
Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit d49b1c254c997195872a9e8913660a788298921e)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416601
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/1f2d0a4e456c29393efc028cc853616a49cba943/drivers/block/zram/zram_drv.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6ef6c1c63eee9cfc1ade3c6c93d07e8fe3bbdb4c

commit 6ef6c1c63eee9cfc1ade3c6c93d07e8fe3bbdb4c
Author: Ganesh Mahendran <opensource.ganesh@gmail.com>
Date: Wed Feb 08 15:26:43 2017

UPSTREAM: zram: use DEVICE_ATTR_[RW|RO|WO] to define zram sys device attribute

In current zram, we use DEVICE_ATTR() to define sys device attributes.
SO, we need to set (S_IRUGO | S_IWUSR) permission and other arguments
manually.  Linux already provids the macro DEVICE_ATTR_[RW|RO|WO] to
define sys device attribute.  It is simple and readable.

This patch uses kernel defined macro DEVICE_ATTR_[RW|RO|WO] to define
zram device attribute.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I22e4b056188704cbb6b392944b84910f86373c55
Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
Acked-by: Jerome Marchand <jmarchan@redhat.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 083914eab96fabddfc715f0436e082eb375c5704)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416602
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/6ef6c1c63eee9cfc1ade3c6c93d07e8fe3bbdb4c/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6a6ca66fe3be5362a9428870ba33e9cb447532a7

commit 6a6ca66fe3be5362a9428870ba33e9cb447532a7
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:26:44 2017

UPSTREAM: zram: clean up zram_meta_alloc()

A trivial cleanup of zram_meta_alloc() error handling.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I2aa2619ea1ddfbbc195593a88972510eedd7e06e
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit b8179958327a1f513efca095ba782a1986c7c4fb)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416603
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/6a6ca66fe3be5362a9428870ba33e9cb447532a7/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/09c092c437392f8510ba34b9c03fd2f44b84c084

commit 09c092c437392f8510ba34b9c03fd2f44b84c084
Author: Ganesh Mahendran <opensource.ganesh@gmail.com>
Date: Wed Feb 08 15:26:45 2017

UPSTREAM: zram: free meta table in zram_meta_free

zram_meta_alloc() and zram_meta_free() are a pair.  In
zram_meta_alloc(), meta table is allocated.  So it it better to free it
in zram_meta_free().

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I64000fdf857b67e54a3ead194bee6ed6fc4b0888
Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 1fec117281d9f5349c35279c9521f4096fa33357)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416604
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/09c092c437392f8510ba34b9c03fd2f44b84c084/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6b3011106a66197acca27d8373a48643d963c324

commit 6b3011106a66197acca27d8373a48643d963c324
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:26:46 2017

UPSTREAM: zram: fix umount-reset_store-mount race condition

Ganesh Mahendran was the first one who proposed to use bdev->bd_mutex to
avoid ->bd_holders race condition:

        CPU0                            CPU1
umount /* zram->init_done is true */
reset_store()
bdev->bd_holders == 0                   mount
...                                     zram_make_request()
zram_reset_device()

However, his solution required some considerable amount of code movement,
which we can avoid.

Apart from using bdev->bd_mutex in reset_store(), this patch also
simplifies zram_reset_device().

zram_reset_device() has a bool parameter reset_capacity which tells it
whether disk capacity and itself disk should be reset.  There are two
zram_reset_device() callers:

-- zram_exit() passes reset_capacity=false
-- reset_store() passes reset_capacity=true

So we can move reset_capacity-sensitive work out of zram_reset_device()
and perform it unconditionally in reset_store().  This also lets us drop
reset_capacity parameter from zram_reset_device() and pass zram pointer
only.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I69516aa1ffb627509fc5a412b2a6c06f385aa927
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reported-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit ba6b17d68c8e3aa8d55d0474299cb931965c5ea5)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416605
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/6b3011106a66197acca27d8373a48643d963c324/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6b30b63dd8388aa15c212f9faca86ad3282a1f37

commit 6b30b63dd8388aa15c212f9faca86ad3282a1f37
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:26:47 2017

UPSTREAM: zram: rework reset and destroy path

We need to return set_capacity(disk, 0) from reset_store() back to
zram_reset_device(), a catch by Ganesh Mahendran.  Potentially, we can
race set_capacity() calls from init and reset paths.

The problem is that zram_reset_device() is also getting called from
zram_exit(), which performs operations in misleading reversed order -- we
first create_device() and then init it, while zram_exit() perform
destroy_device() first and then does zram_reset_device().  This is done to
remove sysfs group before we reset device, so we can continue with device
reset/destruction not being raced by sysfs attr write (f.e.  disksize).

Apart from that, destroy_device() releases zram->disk (but we still have
->disk pointer), so we cannot acces zram->disk in later
zram_reset_device() call, which may cause additional errors in the future.

So, this patch rework and cleanup destroy path.

1) remove several unneeded goto labels in zram_init()

2) factor out zram_init() error path and zram_exit() into
   destroy_devices() function, which takes the number of devices to
   destroy as its argument.

3) remove sysfs group in destroy_devices() first, so we can reorder
   operations -- reset device (as expected) goes before disk destroy and
   queue cleanup.  So we can always access ->disk in zram_reset_device().

4) and, finally, return set_capacity() back under ->init_lock.

[akpm@linux-foundation.org: tweak comment]
BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I6bc71e3f717fec1988c7e2953c34a025939d783e
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reported-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit a096cafc31862c54da0b56c8441dc14023437008)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416606
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/6b30b63dd8388aa15c212f9faca86ad3282a1f37/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7de3e8684f47485fcca8658f565a7b833b00439c

commit 7de3e8684f47485fcca8658f565a7b833b00439c
Author: Minchan Kim <minchan@kernel.org>
Date: Wed Feb 08 15:26:48 2017

UPSTREAM: zram: check bd_openers instead of bd_holders

bd_holders is increased only when user open the device file as FMODE_EXCL
so if something opens zram0 as !FMODE_EXCL and request I/O while another
user reset zram0, we can see following warning.

  zram0: detected capacity change from 0 to 64424509440
  Buffer I/O error on dev zram0, logical block 180823, lost async page write
  Buffer I/O error on dev zram0, logical block 180824, lost async page write
  Buffer I/O error on dev zram0, logical block 180825, lost async page write
  Buffer I/O error on dev zram0, logical block 180826, lost async page write
  Buffer I/O error on dev zram0, logical block 180827, lost async page write
  Buffer I/O error on dev zram0, logical block 180828, lost async page write
  Buffer I/O error on dev zram0, logical block 180829, lost async page write
  Buffer I/O error on dev zram0, logical block 180830, lost async page write
  Buffer I/O error on dev zram0, logical block 180831, lost async page write
  Buffer I/O error on dev zram0, logical block 180832, lost async page write
  ------------[ cut here ]------------
  WARNING: CPU: 11 PID: 1996 at fs/block_dev.c:57 __blkdev_put+0x1d7/0x210()
  Modules linked in:
  CPU: 11 PID: 1996 Comm: dd Not tainted 3.19.0-rc6-next-20150202+ #1125
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  Call Trace:
    dump_stack+0x45/0x57
    warn_slowpath_common+0x8a/0xc0
    warn_slowpath_null+0x1a/0x20
    __blkdev_put+0x1d7/0x210
    blkdev_put+0x50/0x130
    blkdev_close+0x25/0x30
    __fput+0xdf/0x1e0
    ____fput+0xe/0x10
    task_work_run+0xa7/0xe0
    do_notify_resume+0x49/0x60
    int_signal+0x12/0x17
  ---[ end trace 274fbbc5664827d2 ]---

The warning comes from bdev_write_node in blkdev_put path.

   static void bdev_write_inode(struct inode *inode)
   {
        spin_lock(&inode->i_lock);
        while (inode->i_state & I_DIRTY) {
                spin_unlock(&inode->i_lock);
                WARN_ON_ONCE(write_inode_now(inode, true)); <========= here.
                spin_lock(&inode->i_lock);
        }
        spin_unlock(&inode->i_lock);
   }

The reason is dd process encounters I/O fails due to sudden block device
disappear so in filemap_check_errors in __writeback_single_inode returns
-EIO.

If we check bd_openers instead of bd_holders, we could address the
problem.  When I see the brd, it already have used it rather than
bd_holders so although I'm not a expert of block layer, it seems to be
better.

I can make following warning with below simple script.  In addition, I
added msleep(2000) below set_capacity(zram->disk, 0) after applying your
patch to make window huge(Kudos to Ganesh!)

script:

   echo $((60<<30)) > /sys/block/zram0/disksize
   setsid dd if=/dev/zero of=/dev/zram0 &
   sleep 1
   setsid echo 1 > /sys/block/zram0/reset

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I9098e106e0b9219ec6c611496794ce7e8cf5377b
Signed-off-by: Minchan Kim <minchan@kernel.org>
Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Ganesh Mahendran <opensource.ganesh@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 2b269ce6fcbfafc6cae37254cab4bf2309bfed0e)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416607
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/7de3e8684f47485fcca8658f565a7b833b00439c/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c6754df558d517f1a9a8d0b3b9b3c7d7d1f4f57b

commit c6754df558d517f1a9a8d0b3b9b3c7d7d1f4f57b
Author: Minchan Kim <minchan@kernel.org>
Date: Wed Feb 08 15:26:49 2017

BACKPORT: zram: remove init_lock in zram_make_request

Admin could reset zram during I/O operation going on so we have used
zram->init_lock as read-side lock in I/O path to prevent sudden zram
meta freeing.

However, the init_lock is really troublesome.  We can't do call
zram_meta_alloc under init_lock due to lockdep splat because
zram_rw_page is one of the function under reclaim path and hold it as
read_lock while other places in process context hold it as write_lock.
So, we have used allocation out of the lock to avoid lockdep warn but
it's not good for readability and fainally, I met another lockdep splat
between init_lock and cpu_hotplug from kmem_cache_destroy during working
zsmalloc compaction.  :(

Yes, the ideal is to remove horrible init_lock of zram in rw path.  This
patch removes it in rw path and instead, add atomic refcount for meta
lifetime management and completion to free meta in process context.
It's important to free meta in process context because some of resource
destruction needs mutex lock, which could be held if we releases the
resource in reclaim context so it's deadlock, again.

As a bonus, we could remove init_done check in rw path because
zram_meta_get will do a role for it, instead.

BUG=chromium:670864
TEST=build elm

Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Ganesh Mahendran <opensource.ganesh@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[SR: fix up conflict against
  CHROMIUM: Restrict swapon() to "zram" devices / lock down zram]
(cherry picked from commit 08eee69fcf6baea543a2b4d2a2fcba0e61aa3160)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>

Change-Id: I3c3add589db809c1519c30447fc89b2593b94661
Reviewed-on: https://chromium-review.googlesource.com/416608
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>

[modify] https://crrev.com/c6754df558d517f1a9a8d0b3b9b3c7d7d1f4f57b/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/c6754df558d517f1a9a8d0b3b9b3c7d7d1f4f57b/drivers/block/zram/zram_drv.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/520a37c725f4f616dffa59484908648978fbb6ad

commit 520a37c725f4f616dffa59484908648978fbb6ad
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:26:50 2017

UPSTREAM: zram: remove request_queue from struct zram

`struct zram' contains both `struct gendisk' and `struct request_queue'.
the latter can be deleted, because zram->disk carries ->queue pointer, and
->queue carries zram pointer:

create_device()
	zram->queue->queuedata = zram
	zram->disk->queue = zram->queue
	zram->disk->private_data = zram

so zram->queue is not needed, we can access all necessary data anyway.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ie34d4861ba081082162f7a69331dd5e4d82899a3
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit ee98016010ae036a5b27300d83bd99ef3fd5776e)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416609
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/520a37c725f4f616dffa59484908648978fbb6ad/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/520a37c725f4f616dffa59484908648978fbb6ad/drivers/block/zram/zram_drv.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/50a95dcc9743084daa8487930e05c36233c772c4

commit 50a95dcc9743084daa8487930e05c36233c772c4
Author: Joonsoo Kim <js1304@gmail.com>
Date: Wed Feb 08 15:26:51 2017

UPSTREAM: zram: use proper type to update max_used_pages

max_used_pages is defined as atomic_long_t so we need to use unsigned
long to keep temporary value for it rather than int which is smaller
than unsigned long in a 64 bit system.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I0813ea454873375e61f99a7f2666b446ed4db895
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 2ea55a2caee016daee511431217861fb04767b27)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416610
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/50a95dcc9743084daa8487930e05c36233c772c4/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c3a17aa1e22c22e65f289537ad1d855c2a2cf247

commit c3a17aa1e22c22e65f289537ad1d855c2a2cf247
Author: Minchan Kim <minchan@kernel.org>
Date: Wed Feb 08 15:26:52 2017

UPSTREAM: zram: support compaction

Now that zsmalloc supports compaction, zram can use it.  For the first
step, this patch exports compact knob via sysfs so user can do compaction
via "echo 1 > /sys/block/zram0/compact".

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ifae392f79262003ebeafa66ba5c24be09cd3185c
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Juneho Choi <juno.choi@lge.com>
Cc: Gunho Lee <gunho.lee@lge.com>
Cc: Luigi Semenzato <semenzato@google.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 4e3ba87845420e0bfa21e6c4f7f81897aed38f8c)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416611
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/c3a17aa1e22c22e65f289537ad1d855c2a2cf247/Documentation/ABI/testing/sysfs-block-zram
[modify] https://crrev.com/c3a17aa1e22c22e65f289537ad1d855c2a2cf247/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/c3a17aa1e22c22e65f289537ad1d855c2a2cf247/drivers/block/zram/zram_drv.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5e62862781e68ed1722ab2fec02811a647cc8162

commit 5e62862781e68ed1722ab2fec02811a647cc8162
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:26:53 2017

UPSTREAM: zram: remove `num_migrated' device attr

This patch introduces rework to zram stats.  We have per-stat sysfs nodes,
and it makes things a bit hard to use in user space: it doesn't give an
immediate stats 'snapshot', it requires user space to use more syscalls -
open, read, close for every stat file, with appropriate error checks on
every step, etc.

First, zram now accounts block layer statistics, available in
/sys/block/zram<id>/stat and /proc/diskstats files.  So some new stats are
available (see Documentation/block/stat.txt), besides, zram's activities
now can be monitored by sysstat's iostat or similar tools.

Example:
cat /sys/block/zram0/stat
248     0    1984    0   251029     0  2008232   5120   0   5116   5116

Second, group currently exported on per-stat basis nodes into two
categories (files):

-- zram<id>/io_stat
accumulates device's IO stats, that are not accounted by block layer,
and contains:
        failed_reads
        failed_writes
        invalid_io
        notify_free

Example:
cat /sys/block/zram0/io_stat
0        0        0   652572

-- zram<id>/mm_stat
accumulates zram mm stats and contains:
        orig_data_size
        compr_data_size
        mem_used_total
        mem_limit
        mem_used_max
        zero_pages
        num_migrated

Example:
cat /sys/block/zram0/mm_stat
434634752 270288572 279158784        0 579895296    15060        0

per-stat sysfs nodes are now considered to be deprecated and we plan to
remove them (and clean up some of the existing stat code) in two years (as
of now, there is no warning printed to syslog about deprecated stats being
used).  User space is advised to use the above mentioned 3 files.

This patch (of 7):

Remove sysfs `num_migrated' attribute.  We are moving away from per-stat
device attrs towards 3 stat files that will accumulate io and mm stats in
a format similar to block layer statistics in /sys/block/<dev>/stat.  That
will be easier to use in user space, and reduce the number of syscalls
needed to read zram device statistics.

`num_migrated' will return back in zram<id>/mm_stat file.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: If97d416a6975de3efbb476b463045cb9a263256c
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 10447b60bee52f026bdbc5fe2aca52d0492fc91d)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416612
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/5e62862781e68ed1722ab2fec02811a647cc8162/Documentation/ABI/testing/sysfs-block-zram
[modify] https://crrev.com/5e62862781e68ed1722ab2fec02811a647cc8162/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2f9c4c29e2857e9f4508a9e4e2290b092b58328e

commit 2f9c4c29e2857e9f4508a9e4e2290b092b58328e
Author: Gu Zheng <guz.fnst@cn.fujitsu.com>
Date: Wed Feb 08 15:26:54 2017

UPSTREAM: blk: introduce generic io stat accounting help function

Many block drivers accounting io stat based on bio (e.g. NVMe...),
the blk_account_io_start/end() which is based on request
does not make sense to them, so here we introduce the similar help
function named generic_start/end_io_acct base on raw sectors, and it can
simplify some driver's open io accounting code.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I1948e340ec7673c1fe8fd559eabc0a68dbb4f058
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
(cherry picked from commit 394ffa503bc40e32d7f54a9b817264e81ce131b4)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416613
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/2f9c4c29e2857e9f4508a9e4e2290b092b58328e/include/linux/bio.h
[modify] https://crrev.com/2f9c4c29e2857e9f4508a9e4e2290b092b58328e/block/bio.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c7321ec99546088859734d7b78244332f2287470

commit c7321ec99546088859734d7b78244332f2287470
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:26:55 2017

UPSTREAM: zram: use generic start/end io accounting

Use bio generic_start_io_acct() and generic_end_io_acct() to account
device's block layer statistics.  This will let users to monitor zram
activities using sysstat and similar packages/tools.

Apart from the usual per-stat sysfs attr, zram IO stats are now also
available in '/sys/block/zram<id>/stat' and '/proc/diskstats' files.

We will slowly get rid of per-stat sysfs files.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Id2e835690c22000439db2b63c9f3f8e96662bbef
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 8811a9421b325b06a2456ae1b8fe23e838cbfe33)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416614
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/c7321ec99546088859734d7b78244332f2287470/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7e3d27f4cb78f1fd9c172e5836ae4425d96f2dea

commit 7e3d27f4cb78f1fd9c172e5836ae4425d96f2dea
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:26:56 2017

UPSTREAM: zram: describe device attrs in documentation

Briefly describe exported device stat attrs in zram documentation.  We
will eventually get rid of per-stat sysfs nodes and, thus, clean up
Documentation/ABI/testing/sysfs-block-zram file, which is the only source
of information about device sysfs nodes.

Add `num_migrated' description, since there is no independent
`num_migrated' sysfs node (and no corresponding sysfs-block-zram entry),
it will be exported via zram<id>/mm_stat file.

At this point we can provide minimal description, because sysfs-block-zram
still contains detailed information.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I816db668eef42b38b63a43ab0ae9a0ccfbbe4eb7
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 77ba015f9d5c584226a634753e9b318cb272cd41)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416615
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/7e3d27f4cb78f1fd9c172e5836ae4425d96f2dea/Documentation/blockdev/zram.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/eb68e27b8fccdcc53ef61f614e2f40960a295cff

commit eb68e27b8fccdcc53ef61f614e2f40960a295cff
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:26:57 2017

UPSTREAM: zram: export new 'io_stat' sysfs attrs

Per-device `zram<id>/io_stat' file provides accumulated I/O statistics of
particular zram device in a format similar to block layer statistics.  The
file consists of a single line and represents the following stats
(separated by whitespace):

        failed_reads
        failed_writes
        invalid_io
        notify_free

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I7a0a8b68d45f05f983b1086f7a8ce1961d9dc4b3
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 2f6a3bed7347ee94fe57b3501fddaa646a26d890)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416616
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/eb68e27b8fccdcc53ef61f614e2f40960a295cff/Documentation/ABI/testing/sysfs-block-zram
[modify] https://crrev.com/eb68e27b8fccdcc53ef61f614e2f40960a295cff/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/eb68e27b8fccdcc53ef61f614e2f40960a295cff/Documentation/blockdev/zram.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/aa480dc7747c5c554796fcbbc01da842ce6abfb8

commit aa480dc7747c5c554796fcbbc01da842ce6abfb8
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:26:58 2017

UPSTREAM: zram: export new 'mm_stat' sysfs attrs

Per-device `zram<id>/mm_stat' file provides mm statistics of a particular
zram device in a format similar to block layer statistics.  The file
consists of a single line and represents the following stats (separated by
whitespace):

        orig_data_size
        compr_data_size
        mem_used_total
        mem_limit
        mem_used_max
        zero_pages
        num_migrated

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I9888bcf0c896e595e329fc9b665ff4d2256591ee
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 4f2109f60881585dc04fa0b5657a60556576625c)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416617
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/aa480dc7747c5c554796fcbbc01da842ce6abfb8/Documentation/ABI/testing/sysfs-block-zram
[modify] https://crrev.com/aa480dc7747c5c554796fcbbc01da842ce6abfb8/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/aa480dc7747c5c554796fcbbc01da842ce6abfb8/Documentation/blockdev/zram.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/dc7a8b4813e878057d813ce5b0b3c7ea25fe248d

commit dc7a8b4813e878057d813ce5b0b3c7ea25fe248d
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:26:59 2017

UPSTREAM: zram: deprecate zram attrs sysfs nodes

Add Documentation/ABI/obsolete/sysfs-block-zram file and list obsolete and
deprecated attributes there.  The patch also adds additional information
to zram documentation and describes the basic strategy:

- the existing RW nodes will be downgraded to WO nodes (in 4.11)
- deprecated RO sysfs nodes will eventually be removed (in 4.11)

Users will be additionally notified about deprecated attr usage by
pr_warn_once() (added to every deprecated attr _show()), as suggested by
Minchan Kim.

User space is advised to use zram<id>/stat, zram<id>/io_stat and
zram<id>/mm_stat files.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ia035ac52dddcd5b59daa475a0c76b5e239e9962b
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reported-by: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 8f7d282c717acaae25245c61b6b60e8995ec4ef4)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416618
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/dc7a8b4813e878057d813ce5b0b3c7ea25fe248d/drivers/block/zram/zram_drv.c
[add] https://crrev.com/dc7a8b4813e878057d813ce5b0b3c7ea25fe248d/Documentation/ABI/obsolete/sysfs-block-zram
[modify] https://crrev.com/dc7a8b4813e878057d813ce5b0b3c7ea25fe248d/Documentation/blockdev/zram.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/3cd8e62e48a635a431982b95dd087d11461da1ab

commit 3cd8e62e48a635a431982b95dd087d11461da1ab
Author: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Wed Feb 08 15:27:00 2017

UPSTREAM: zram: fix error return code

Return a negative error code on failure.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}
// </smpl>

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ia1d7cb91b3b81cfc3f33f3062ccfe575bda92441
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Acked-by: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 201c7b72f0bf38d7f31fd229a01de035d0f10cd1)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416619
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/3cd8e62e48a635a431982b95dd087d11461da1ab/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/142b7bc2939c4afb0d034f3626eab722cb503afd

commit 142b7bc2939c4afb0d034f3626eab722cb503afd
Author: Weijie Yang <weijie.yang@samsung.com>
Date: Wed Feb 08 15:27:02 2017

UPSTREAM: zram: clear disk io accounting when reset zram device

Clear zram disk io accounting when resetting the zram device.  Otherwise
the residual io accounting stat will affect the diskstat in the next
zram active cycle.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ifee4f51eb5609278eaddc127c018f2e7ef062ae2
Signed-off-by: Weijie Yang <weijie.yang@samsung.com>
Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit d7ad41a1c498729b7584c257710b1b437a0c1470)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416620
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/142b7bc2939c4afb0d034f3626eab722cb503afd/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b87b9b3d0f469aacffcc826335df5ecee23528e9

commit b87b9b3d0f469aacffcc826335df5ecee23528e9
Author: Marcin Jabrzyk <m.jabrzyk@samsung.com>
Date: Wed Feb 08 15:27:03 2017

UPSTREAM: zram: remove obsolete ZRAM_DEBUG option

This config option doesn't provide any usage for zram.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I2da7958db5c3c56e106301df32b658d3e30da35f
Signed-off-by: Marcin Jabrzyk <m.jabrzyk@samsung.com>
Acked-by: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 9e65bf68a8f14f1b3fb16dc85dbbaff79da4bfeb)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416621
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/b87b9b3d0f469aacffcc826335df5ecee23528e9/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/b87b9b3d0f469aacffcc826335df5ecee23528e9/drivers/block/zram/Kconfig

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/cbb7309c11a3664cd8d8cab36ac28526ad75f2ee

commit cbb7309c11a3664cd8d8cab36ac28526ad75f2ee
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:27:04 2017

UPSTREAM: zram: cosmetic ZRAM_ATTR_RO code formatting tweak

Fix a misplaced backslash.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ia03e9b4eb23047fbaa07fbecde0001db8bcefb11
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 3bca3ef7694166b86c91b515818cc5acecd357a7)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416622
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/cbb7309c11a3664cd8d8cab36ac28526ad75f2ee/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4431925f3b512aad6fc1f97fbee0b53b6e3ce535

commit 4431925f3b512aad6fc1f97fbee0b53b6e3ce535
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:27:05 2017

UPSTREAM: zram: use idr instead of `zram_devices' array

This patch makes some preparations for on-demand device add/remove
functionality.

Remove `zram_devices' array and switch to id-to-pointer translation (idr).
idr doesn't bloat zram struct with additional members, f.e.  list_head,
yet still provides ability to match the device_id with the device pointer.

No user-space visible changes.

[Julia.Lawall@lip6.fr: return -ENOMEM when `queue' alloc fails]
BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I7c03f9f17910d14c9e2999de9cce360953a53790
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reported-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 85508ec6cbc21645927b6ac05e3b2748119a3e23)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416623
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/4431925f3b512aad6fc1f97fbee0b53b6e3ce535/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8731eeb533e5fb6809919966c2b0553994d99c56

commit 8731eeb533e5fb6809919966c2b0553994d99c56
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:27:06 2017

BACKPORT: zram: reorganize code layout

This patch looks big, but basically it just moves code blocks.
No functional changes.

Our current code layout looks like a sandwitch.

For example,
a) between read/write handlers, we have update_used_max() helper function:

static int zram_decompress_page
static int zram_bvec_read
static inline void update_used_max
static int zram_bvec_write
static int zram_bvec_rw

b) RW request handlers __zram_make_request/zram_bio_discard are divided by
sysfs attr reset_store() function and corresponding zram_reset_device()
handler:

static void zram_bio_discard
static void zram_reset_device
static ssize_t disksize_store
static ssize_t reset_store
static void __zram_make_request

c) we first a bunch of sysfs read/store functions. then a number of
one-liners, then helper functions, RW functions, sysfs functions, helper
functions again, and so on.

Reorganize layout to be more logically grouped (a brief description,
`cat zram_drv.c | grep static` gives a bigger picture):

-- one-liners: zram_test_flag/etc.

-- helpers: is_partial_io/update_position/etc

-- sysfs attr show/store functions + ZRAM_ATTR_RO() generated stats
show() functions
exception: reset and disksize store functions are required to be after
meta() functions. because we do device create/destroy actions in these
sysfs handlers.

-- "mm" functions: meta get/put, meta alloc/free, page free
static inline bool zram_meta_get
static inline void zram_meta_put
static void zram_meta_free
static struct zram_meta *zram_meta_alloc
static void zram_free_page

-- a block of I/O functions
static int zram_decompress_page
static int zram_bvec_read
static int zram_bvec_write
static void zram_bio_discard
static int zram_bvec_rw
static void __zram_make_request
static void zram_make_request
static void zram_slot_free_notify
static int zram_rw_page

-- device contol: add/remove/init/reset functions (+zram-control class
will sit here)
static int zram_reset_device
static ssize_t reset_store
static ssize_t disksize_store
static int zram_add
static void zram_remove
static int __init zram_init
static void __exit zram_exit

BUG=chromium:670864
TEST=build/boot elm

Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 522698d7cadb5d208429c934f673713b7a42e925)
[SR: fix trivial conflict against Chromium specific code]
Conflicts:
	drivers/block/zram/zram_drv.c
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>

Change-Id: I54e9a4c28661dc1ddfad4f4f47c68c2e51d5694e
Reviewed-on: https://chromium-review.googlesource.com/416624
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>

[modify] https://crrev.com/8731eeb533e5fb6809919966c2b0553994d99c56/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0a0789da27b581af165046ee211c43dcb13a601d

commit 0a0789da27b581af165046ee211c43dcb13a601d
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:27:07 2017

UPSTREAM: zram: remove max_num_devices limitation

Limiting the number of zram devices to 32 (default max_num_devices value)
is confusing, let's drop it.  A user with 2TB or 4TB of RAM, for example,
can request as many devices as he can handle.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I5767089b87a7a14e84eaab29a9cd53af36a09285
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit c3cdb40e66344553898daa3ccd068c03173a3f42)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416625
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/0a0789da27b581af165046ee211c43dcb13a601d/drivers/block/zram/zram_drv.h
[modify] https://crrev.com/0a0789da27b581af165046ee211c43dcb13a601d/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/0a0789da27b581af165046ee211c43dcb13a601d/Documentation/blockdev/zram.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0d9b4560ddf31fe691e63a324c95175919bc38fc

commit 0d9b4560ddf31fe691e63a324c95175919bc38fc
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 15:27:09 2017

UPSTREAM: zram: report every added and removed device

With dynamic device creation/removal (which will be introduced later in
the series) printing num_devices in zram_init() will not make a lot of
sense, as well as printing the number of destroyed devices in
destroy_devices().  Print per-device action (added/removed) in zram_add()
and zram_remove() instead.

Example:

[ 3645.259652] zram: Added device: zram5
[ 3646.152074] zram: Added device: zram6
[ 3650.585012] zram: Removed device: zram5
[ 3655.845584] zram: Added device: zram8
[ 3660.975223] zram: Removed device: zram6

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I9b445a5f13457777a5c8a106ce8847b428a4cef6
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit d12b63c927e0e90de4b55d5084f947707c6d8cf4)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416626
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/0d9b4560ddf31fe691e63a324c95175919bc38fc/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4555d7003532d387cf15e38215690ba9c51cb6da

commit 4555d7003532d387cf15e38215690ba9c51cb6da
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 17:19:44 2017

UPSTREAM: zram: trivial: correct flag operations comment

We don't have meta->tb_lock anymore and use meta table entry bit_spin_lock
instead. update corresponding comment.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ice509c36451ba9ac52c8b54985dfa4e31a66953a
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit b31177f2a9d5b2cfb1da7a06a4a98273b40975a8)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416627
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/4555d7003532d387cf15e38215690ba9c51cb6da/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/bf8849108f60310af36a98bc180a418972046190

commit bf8849108f60310af36a98bc180a418972046190
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Wed Feb 08 17:19:45 2017

UPSTREAM: zram: return zram device_id from zram_add()

This patch prepares zram to enable on-demand device creation.
zram_add() performs automatic device_id assignment and returns
new device id (>= 0) or error code (< 0).

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I99d15be03de557586b2b8d8127fdc3ec02490c35
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 92ff15288747b80730f0132e9c98403370c27b34)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416628
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/bf8849108f60310af36a98bc180a418972046190/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/867afda90420a049f079b276c370d6b9e54893c1

commit 867afda90420a049f079b276c370d6b9e54893c1
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:02 2017

BACKPORT: zram: close race by open overriding

[ Original patch from Minchan Kim <minchan@kernel.org> ]

Commit ba6b17d68c8e ("zram: fix umount-reset_store-mount race
condition") introduced bdev->bd_mutex to protect a race between mount
and reset.  At that time, we don't have dynamic zram-add/remove feature
so it was okay.

However, as we introduce dynamic device feature, bd_mutex became
trouble.

	CPU 0

echo 1 > /sys/block/zram<id>/reset
  -> kernfs->s_active(A)
    -> zram:reset_store->bd_mutex(B)

	CPU 1

echo <id> > /sys/class/zram/zram-remove
  ->zram:zram_remove: bd_mutex(B)
  -> sysfs_remove_group
    -> kernfs->s_active(A)

IOW, AB -> BA deadlock

The reason we are holding bd_mutex for zram_remove is to prevent
any incoming open /dev/zram[0-9]. Otherwise, we could remove zram
others already have opened. But it causes above deadlock problem.

To fix the problem, this patch overrides block_device.open and
it returns -EBUSY if zram asserts he claims zram to reset so any
incoming open will be failed so we don't need to hold bd_mutex
for zram_remove ayn more.

This patch is to prepare for zram-add/remove feature.

BUG=chromium:670864
TEST=build/boot elm

[sergey.senozhatsky@gmail.com: simplify reset_store()]
Signed-off-by: Minchan Kim <minchan@kernel.org>
Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit f405c445a4866caa43101c231721123805a23bbf)
[SR: merge Chromium zram_open function with new zram_open]
 Conflicts:
	drivers/block/zram/zram_drv.c
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>

Change-Id: I9238fcfe3c830518db5ecce42676ae2816359ec2
Reviewed-on: https://chromium-review.googlesource.com/416629
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>

[modify] https://crrev.com/867afda90420a049f079b276c370d6b9e54893c1/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/867afda90420a049f079b276c370d6b9e54893c1/drivers/block/zram/zram_drv.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/255388096d88f5d5383a1bca0f8e35648d0a6d10

commit 255388096d88f5d5383a1bca0f8e35648d0a6d10
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:03 2017

UPSTREAM: zram: add dynamic device add/remove functionality

We currently don't support on-demand device creation.  The one and only
way to have N zram devices is to specify num_devices module parameter
(default value: 1).  IOW if, for some reason, at some point, user wants
to have N + 1 devies he/she must umount all the existing devices, unload
the module, load the module passing num_devices equals to N + 1.  And do
this again, if needed.

This patch introduces zram control sysfs class, which has two sysfs
attrs:
- hot_add      -- add a new zram device
- hot_remove   -- remove a specific (device_id) zram device

hot_add sysfs attr is read-only and has only automatic device id
assignment mode (as requested by Minchan Kim).  read operation performed
on this attr creates a new zram device and returns back its device_id or
error status.

Usage example:
	# add a new specific zram device
	cat /sys/class/zram-control/hot_add
	2

	# remove a specific zram device
	echo 4 > /sys/class/zram-control/hot_remove

Returning zram_add() error code back to user (-ENOMEM in this case)

	cat /sys/class/zram-control/hot_add
	cat: /sys/class/zram-control/hot_add: Cannot allocate memory

NOTE, there might be users who already depend on the fact that at least
zram0 device gets always created by zram_init(). Preserve this behavior.

[minchan@kernel.org: use zram->claim to avoid lockdep splat]
BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I831ceb39fde9982684984c2c545805d8bd0f96c6
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 6566d1a32bf725a4fa9119f16270505451ad01ac)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416630
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[add] https://crrev.com/255388096d88f5d5383a1bca0f8e35648d0a6d10/Documentation/ABI/testing/sysfs-class-zram
[modify] https://crrev.com/255388096d88f5d5383a1bca0f8e35648d0a6d10/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/255388096d88f5d5383a1bca0f8e35648d0a6d10/Documentation/blockdev/zram.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b63737299de84571bca824d7147ec9011d6c9b03

commit b63737299de84571bca824d7147ec9011d6c9b03
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:04 2017

UPSTREAM: zram: cosmetic zram_bvec_write() cleanup

`bool locked' local variable tells us if we should perform
zcomp_strm_release() or not (jumped to `out' label before
zcomp_strm_find() occurred), which is equivalent to `zstrm' being or not
being NULL.  remove `locked' and check `zstrm' instead.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I1784cbedacef5cdcc44942d3be598d8a149e443c
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 17162f41f04a3ba5a6b887a8e8e7f78159fa4a70)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416631
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/b63737299de84571bca824d7147ec9011d6c9b03/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a81dc18a2ff54999ca03053c5e26cb005cf17e10

commit a81dc18a2ff54999ca03053c5e26cb005cf17e10
Author: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Date: Thu Feb 09 04:31:05 2017

UPSTREAM: zram: cut trailing newline in algorithm name

Supplied sysfs values sometimes contain new-line symbols (echo vs.  echo
-n), which we also copy as a compression algorithm name.  it works fine
when we lookup for compression algorithm, because we use sysfs_streq()
which takes care of new line symbols.  however, it doesn't look nice when
we print compression algorithm name if zcomp_create() failed:

 zram: Cannot initialise LXZ
            compressing backend

cut trailing new-line, so the error string will look like

  zram: Cannot initialise LXZ compressing backend

we also now can replace sysfs_streq() in zcomp_available_show() with
strcmp().

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I875ab170ab10a679d324dc7ffdeb2f6fdf3a4683
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 4bbacd51a683e45c13f7d6df6f85cb7391590311)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416632
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/a81dc18a2ff54999ca03053c5e26cb005cf17e10/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/a81dc18a2ff54999ca03053c5e26cb005cf17e10/drivers/block/zram/zcomp.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/55d9b38b176f949d625e0e69079fdd450846122e

commit 55d9b38b176f949d625e0e69079fdd450846122e
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:07 2017

UPSTREAM: zram: check comp algorithm availability earlier

Improvement idea by Marcin Jabrzyk.

comp_algorithm_store() silently accepts any supplied algorithm name,
because zram performs algorithm availability check later, during the
device configuration phase in disksize_store() and emits the following
error:

  "zram: Cannot initialise %s compressing backend"

this error line is somewhat generic and, besides, can indicate a failed
attempt to allocate compression backend's working buffers.

add algorithm availability check to comp_algorithm_store():

  echo lzz > /sys/block/zram0/comp_algorithm
  -bash: echo: write error: Invalid argument

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I884214a559b91bc75452530b6acc1ce87570712e
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reported-by: Marcin Jabrzyk <m.jabrzyk@samsung.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit d93435c3fba4a47b773693b0c8992470d38510d5)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416633
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/55d9b38b176f949d625e0e69079fdd450846122e/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/55d9b38b176f949d625e0e69079fdd450846122e/drivers/block/zram/zcomp.c
[modify] https://crrev.com/55d9b38b176f949d625e0e69079fdd450846122e/drivers/block/zram/zcomp.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/fb466aacde524d4dd265990ff30e6c75777f1fe6

commit fb466aacde524d4dd265990ff30e6c75777f1fe6
Author: Jens Axboe <axboe@fb.com>
Date: Thu Feb 09 04:31:43 2017

BACKPORT: block: have drivers use blk_queue_max_discard_sectors()

Some drivers use it now, others just set the limits field manually.
But in preparation for splitting this into a hard and soft limit,
ensure that they all call the proper function for setting the hw
limit for discards.

BUG=chromium:670864
TEST=build boot/elm

Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
(cherry picked from commit 2bb4cd5cc472b191a46938becb7dafdd44644329)
[SR: fix up trivial conflict, function moved]
 Conflicts:
	drivers/block/nvme-core.c
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>

Change-Id: Ia6943a6312ed301c2c1fe90f24abb782ad51038b
Reviewed-on: https://chromium-review.googlesource.com/416634
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>

[modify] https://crrev.com/fb466aacde524d4dd265990ff30e6c75777f1fe6/drivers/scsi/sd.c
[modify] https://crrev.com/fb466aacde524d4dd265990ff30e6c75777f1fe6/drivers/block/nbd.c
[modify] https://crrev.com/fb466aacde524d4dd265990ff30e6c75777f1fe6/drivers/block/brd.c
[modify] https://crrev.com/fb466aacde524d4dd265990ff30e6c75777f1fe6/drivers/mmc/card/queue.c
[modify] https://crrev.com/fb466aacde524d4dd265990ff30e6c75777f1fe6/drivers/block/nvme-core.c
[modify] https://crrev.com/fb466aacde524d4dd265990ff30e6c75777f1fe6/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/fb466aacde524d4dd265990ff30e6c75777f1fe6/drivers/block/skd_main.c
[modify] https://crrev.com/fb466aacde524d4dd265990ff30e6c75777f1fe6/drivers/md/bcache/super.c
[modify] https://crrev.com/fb466aacde524d4dd265990ff30e6c75777f1fe6/drivers/mtd/mtd_blkdevs.c
[modify] https://crrev.com/fb466aacde524d4dd265990ff30e6c75777f1fe6/drivers/block/rbd.c
[modify] https://crrev.com/fb466aacde524d4dd265990ff30e6c75777f1fe6/drivers/block/loop.c
[modify] https://crrev.com/fb466aacde524d4dd265990ff30e6c75777f1fe6/drivers/block/drbd/drbd_nl.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4f744ac5c91cc73b77543ee158de7c2a3d5eb76d

commit 4f744ac5c91cc73b77543ee158de7c2a3d5eb76d
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:09 2017

UPSTREAM: zram: fix pool name truncation

zram_meta_alloc() constructs a pool name for zs_create_pool() call as

    snprintf(pool_name, sizeof(pool_name), "zram%d", device_id);

However, it defines pool name buffer to be only 8 bytes long (minus
trailing zero), which means that we can have only 1000 pool names: zram0
-- zram999.

With CONFIG_ZSMALLOC_STAT enabled an attempt to create a device zram1000
can fail if device zram100 already exists, because snprintf() will
truncate new pool name to zram100 and pass it debugfs_create_dir(),
causing:

  debugfs dir <zram100> creation failed
  zram: Error creating memory pool

... and so on.

Fix it by passing zram->disk->disk_name to zram_meta_alloc() instead of
divice_id.  We construct zram%d name earlier and keep it as a ->disk_name,
no need to snprintf() it again.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ie77775c2e0ee916f6d89c18058799c66ae8e0139
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 4ce321f574a97f3453bca5a4117610b43dabd3ee)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416635
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/4f744ac5c91cc73b77543ee158de7c2a3d5eb76d/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b754b6d643f82b8f1dd41c394b6524372595e620

commit b754b6d643f82b8f1dd41c394b6524372595e620
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:11 2017

UPSTREAM: zsmalloc/zram: introduce zs_pool_stats api

`zs_compact_control' accounts the number of migrated objects but it has
a limited lifespan -- we lose it as soon as zs_compaction() returns back
to zram.  It worked fine, because (a) zram had it's own counter of
migrated objects and (b) only zram could trigger compaction.  However,
this does not work for automatic pool compaction (not issued by zram).
To account objects migrated during auto-compaction (issued by the
shrinker) we need to store this number in zs_pool.

Define a new `struct zs_pool_stats' structure to keep zs_pool's stats
there.  It provides only `num_migrated', as of this writing, but it
surely can be extended.

A new zsmalloc zs_pool_stats() symbol exports zs_pool's stats back to
caller.

Use zs_pool_stats() in zram and remove `num_migrated' from zram_stats.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I780695a2ae802773ec127f38cfd9a0abf4b2f105
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Suggested-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 7d3f3938236b4bb878214e6791e76fd8409bdeee)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416636
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/b754b6d643f82b8f1dd41c394b6524372595e620/mm/zsmalloc.c
[modify] https://crrev.com/b754b6d643f82b8f1dd41c394b6524372595e620/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/b754b6d643f82b8f1dd41c394b6524372595e620/include/linux/zsmalloc.h
[modify] https://crrev.com/b754b6d643f82b8f1dd41c394b6524372595e620/drivers/block/zram/zram_drv.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/65a2117da5b84a3389abd922335cc3f1afd53248

commit 65a2117da5b84a3389abd922335cc3f1afd53248
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:14 2017

UPSTREAM: zram: add `compact` sysfs entry to documentation

We currently don't support zram on-demand device creation.  The only way
to have N zram devices is to specify num_devices module parameter (default
value 1).  That means that if, for some reason, at some point, user wants
to have N + 1 devies he/she must umount all the existing devices, unload
the module, load the module passing num_devices equals to N + 1.

This patchset introduces zram-control sysfs class, which has two sysfs
attrs:

 - hot_add     -- add a new zram device
 - hot_remove  -- remove a specific (device_id) zram device

    Usage example:
        # add a new specific zram device
        cat /sys/class/zram-control/hot_add
        1

        # remove a specific zram device
        echo 4 > /sys/class/zram-control/hot_remove

This patch (of 10):

Briefly describe missing `compact` sysfs entry.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ia8c752a223702e79554336c37412e63b73aaf7fa
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 3d8ed88ba7f612305785fc1f3cefa043f817bb3e)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416637
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/65a2117da5b84a3389abd922335cc3f1afd53248/Documentation/blockdev/zram.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/dc66773394abb1199f18abf9a42a2299e17abbed

commit dc66773394abb1199f18abf9a42a2299e17abbed
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:17 2017

UPSTREAM: zsmalloc: account the number of compacted pages

Compaction returns back to zram the number of migrated objects, which is
quite uninformative -- we have objects of different sizes so user space
cannot obtain any valuable data from that number.  Change compaction to
operate in terms of pages and return back to compaction issuer the
number of pages that were freed during compaction.  So from now on we
will export more meaningful value in zram<id>/mm_stat -- the number of
freed (compacted) pages.

This requires:
 (a) a rename of `num_migrated' to 'pages_compacted'
 (b) a internal API change -- return first_page's fullness_group from
     putback_zspage(), so we know when putback_zspage() did
     free_zspage().  It helps us to account compaction stats correctly.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: If7de9f916465f42cab24956994e1356f3f8130e8
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 860c707dca155a56dfa115ddd6c00959296144a6)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416638
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/dc66773394abb1199f18abf9a42a2299e17abbed/mm/zsmalloc.c
[modify] https://crrev.com/dc66773394abb1199f18abf9a42a2299e17abbed/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/dc66773394abb1199f18abf9a42a2299e17abbed/include/linux/zsmalloc.h
[modify] https://crrev.com/dc66773394abb1199f18abf9a42a2299e17abbed/Documentation/blockdev/zram.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/d821794bd0f7f64777b9dba3f0537618a093a24d

commit d821794bd0f7f64777b9dba3f0537618a093a24d
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:18 2017

UPSTREAM: zram: unify error reporting

Make zram syslog error reporting more consistent. We have random
error levels in some places. For example, critical errors like
  "Error allocating memory for compressed page"
and
  "Unable to allocate temp memory"
are reported as KERN_INFO messages.

a) Reassign error levels

Error messages that directly affect zram
functionality -- pr_err():

 Error allocating zram address table
 Error creating memory pool
 Decompression failed! err=%d, page=%u
 Unable to allocate temp memory
 Compression failed! err=%d
 Error allocating memory for compressed page: %u, size=%zu
 Cannot initialise %s compressing backend
 Error allocating disk queue for device %d
 Error allocating disk structure for device %d
 Error creating sysfs group for device %d
 Unable to register zram-control class
 Unable to get major number

Messages that do not affect functionality, but user
must be warned (because sysfs attrs will be removed in
this particular case) -- pr_warn():

 %d (%s) Attribute %s (and others) will be removed. %s

Messages that do not affect functionality and mostly are
informative -- pr_info():

 Cannot change max compression streams
 Can't change algorithm for initialized device
 Cannot change disksize for initialized device
 Added device: %s
 Removed device: %s

b) Update sysfs_create_group() error message

First, it lacks a trailing new line; add it.  Second, every error message
in zram_add() has a "for device %d" part, which makes errors more
informative.  Add missing part to "Error creating sysfs group" message.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I8e30907dde45ea106c87d25b70bdf4538bc42661
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 708649694a8699ff91d395c4aef5ecea3ade14bc)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416639
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/d821794bd0f7f64777b9dba3f0537618a093a24d/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/dfbbf9bb1a2871825243e887852c6cdc11b9f0a6

commit dfbbf9bb1a2871825243e887852c6cdc11b9f0a6
Author: Luis Henriques <luis.henriques@canonical.com>
Date: Thu Feb 09 04:31:19 2017

UPSTREAM: zram: fix possible use after free in zcomp_create()

zcomp_create() verifies the success of zcomp_strm_{multi,single}_create()
through comp->stream, which can potentially be pointing to memory that
was freed if these functions returned an error.

While at it, replace a 'ERR_PTR(-ENOMEM)' by a more generic
'ERR_PTR(error)' as in the future zcomp_strm_{multi,siggle}_create()
could return other error codes.  Function documentation updated
accordingly.

Fixes: beca3ec71fe5 ("zram: add multi stream functionality")
BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I074a97b30e80a722f440f5edafb462635168d56b
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 3aaf14da807a4e9931a37f21e4251abb8a67021b)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416640
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/dfbbf9bb1a2871825243e887852c6cdc11b9f0a6/drivers/block/zram/zcomp.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/cf218755cb47973e8890ce7bbf0e2cf152d620d0

commit cf218755cb47973e8890ce7bbf0e2cf152d620d0
Author: Luis Henriques <luis.henriques@canonical.com>
Date: Thu Feb 09 04:31:20 2017

UPSTREAM: zram: introduce comp algorithm fallback functionality

When the user supplies an unsupported compression algorithm, keep the
previously selected one (knowingly supported) or the default one (if the
compression algorithm hasn't been changed yet).

Note that previously this operation (i.e. setting an invalid algorithm)
would result in no algorithm being selected, which means that this
represents a small change in the default behaviour.

Minchan said:

For initializing zram, we need to set up 3 optional parameters in advance.

1. the number of compression streams
2. memory limitation
3. compression algorithm

Although user pass completely wrong value to set up for 1 and 2
parameters, it's okay because they have default value so zram will be
initialized with the default value (of course, when user passes a wrong
value via *echo*, sysfs returns -EINVAL so the user can notice it).

But 3 is not consistent with other optional parameters.  IOW, if the
user passes a wrong value to set up 3 parameter, zram's initialization
would fail unlike other optional parameters.

So this patch makes them consistent.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ic51cfb774ad44b43fbd4d3d6c4caf1c6b8892eba
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 1d5b43bfb60f7ba2b51792978a6b0781d4ebba93)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416641
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/cf218755cb47973e8890ce7bbf0e2cf152d620d0/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8fd58259cd79073612c890d3ddf859d5061393f2

commit 8fd58259cd79073612c890d3ddf859d5061393f2
Author: Sergey SENOZHATSKY <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:21 2017

UPSTREAM: zram: keep the exact overcommited value in mem_used_max

`mem_used_max' is designed to store the max amount of memory zram consumed
to store the data.  However, it does not represent the actual
'overcommited' (max) value.  The existing code goes to -ENOMEM
overcommited case before it updates `->stats.max_used_pages', which hides
the reason we went to -ENOMEM in the first place -- we actually used more
memory than `->limit_pages':

        alloced_pages = zs_get_total_pages(meta->mem_pool);
        if (zram->limit_pages && alloced_pages > zram->limit_pages) {
                zs_free(meta->mem_pool, handle);
                ret = -ENOMEM;
                goto out;
        }

        update_used_max(zram, alloced_pages);

Which is misleading.  User will see -ENOMEM, check `->limit_pages', check
`->stats.max_used_pages', which will keep the value BEFORE zram passed
`->limit_pages', and see:
	`->stats.max_used_pages' < `->limit_pages'

Move update_used_max() before we do `->limit_pages' check, so that
user will see:
	`->stats.max_used_pages' > `->limit_pages'
should the overcommit and -ENOMEM happen.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I0101c2a5ad840493174dbab00587b30574490d1b
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 1237275580f3e2b998d355b2ff7f84c6b423aa11)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416642
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/8fd58259cd79073612c890d3ddf859d5061393f2/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/d800e1eb6854db2bc5347628fcbf317f14535821

commit d800e1eb6854db2bc5347628fcbf317f14535821
Author: Geliang Tang <geliangtang@163.com>
Date: Thu Feb 09 04:31:22 2017

UPSTREAM: zram: make is_partial_io/valid_io_request/page_zero_filled return boolean

Make is_partial_io()/valid_io_request()/page_zero_filled() return boolean,
since each function only uses either one or zero as its return value.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ifab5838a9a9ea9f6ecc42b072f13654442b3fab0
Signed-off-by: Geliang Tang <geliangtang@163.com>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 1c53e0d2737f3ce4afa27d5703494eb14610ec26)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416643
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/d800e1eb6854db2bc5347628fcbf317f14535821/drivers/block/zram/zram_drv.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/af7962a17b522812067d38fbea7f80867a4d8177

commit af7962a17b522812067d38fbea7f80867a4d8177
Author: Sonny Rao <sonnyrao@chromium.org>
Date: Thu Feb 09 04:31:23 2017

Revert "CHROMIUM: zram: lz4: fallback to vmalloc allocation"

This reverts commit 90407b381f3fea4fc31382b06586eba803d8a48a.

It is superceded by the upstream commit
  d913897 zram: try vmalloc() after kmalloc()

BUG=chromium:670864
TEST=build elm

Change-Id: If4b345034156512833d503a64789939c00f196ca
Reviewed-on: https://chromium-review.googlesource.com/416644
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>

[modify] https://crrev.com/af7962a17b522812067d38fbea7f80867a4d8177/drivers/block/zram/zcomp_lz4.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/409f66e1e2ce52456ecb438a611ee8c327cc7306

commit 409f66e1e2ce52456ecb438a611ee8c327cc7306
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:25 2017

UPSTREAM: zram/zcomp: use GFP_NOIO to allocate streams

We can end up allocating a new compression stream with GFP_KERNEL from
within the IO path, which may result is nested (recursive) IO
operations.  That can introduce problems if the IO path in question is a
reclaimer, holding some locks that will deadlock nested IOs.

Allocate streams and working memory using GFP_NOIO flag, forbidding
recursive IO and FS operations.

An example:

  inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage.
  git/20158 [HC0[0]:SC0[0]:HE1:SE1] takes:
   (jbd2_handle){+.+.?.}, at:  start_this_handle+0x4ca/0x555
  {IN-RECLAIM_FS-W} state was registered at:
     __lock_acquire+0x8da/0x117b
     lock_acquire+0x10c/0x1a7
     start_this_handle+0x52d/0x555
     jbd2__journal_start+0xb4/0x237
     __ext4_journal_start_sb+0x108/0x17e
     ext4_dirty_inode+0x32/0x61
     __mark_inode_dirty+0x16b/0x60c
     iput+0x11e/0x274
     __dentry_kill+0x148/0x1b8
     shrink_dentry_list+0x274/0x44a
     prune_dcache_sb+0x4a/0x55
     super_cache_scan+0xfc/0x176
     shrink_slab.part.14.constprop.25+0x2a2/0x4d3
     shrink_zone+0x74/0x140
     kswapd+0x6b7/0x930
     kthread+0x107/0x10f
     ret_from_fork+0x3f/0x70
  irq event stamp: 138297
  hardirqs last  enabled at (138297):  debug_check_no_locks_freed+0x113/0x12f
  hardirqs last disabled at (138296):  debug_check_no_locks_freed+0x33/0x12f
  softirqs last  enabled at (137818):  __do_softirq+0x2d3/0x3e9
  softirqs last disabled at (137813):  irq_exit+0x41/0x95

               other info that might help us debug this:
   Possible unsafe locking scenario:
         CPU0
         ----
    lock(jbd2_handle);
    <Interrupt>
      lock(jbd2_handle);

                *** DEADLOCK ***
  5 locks held by git/20158:
   #0:  (sb_writers#7){.+.+.+}, at: [<ffffffff81155411>] mnt_want_write+0x24/0x4b
   #1:  (&type->i_mutex_dir_key#2/1){+.+.+.}, at: [<ffffffff81145087>] lock_rename+0xd9/0xe3
   #2:  (&sb->s_type->i_mutex_key#11){+.+.+.}, at: [<ffffffff8114f8e2>] lock_two_nondirectories+0x3f/0x6b
   #3:  (&sb->s_type->i_mutex_key#11/4){+.+.+.}, at: [<ffffffff8114f909>] lock_two_nondirectories+0x66/0x6b
   #4:  (jbd2_handle){+.+.?.}, at: [<ffffffff811e31db>] start_this_handle+0x4ca/0x555

               stack backtrace:
  CPU: 2 PID: 20158 Comm: git Not tainted 4.1.0-rc7-next-20150615-dbg-00016-g8bdf555-dirty #211
  Call Trace:
    dump_stack+0x4c/0x6e
    mark_lock+0x384/0x56d
    mark_held_locks+0x5f/0x76
    lockdep_trace_alloc+0xb2/0xb5
    kmem_cache_alloc_trace+0x32/0x1e2
    zcomp_strm_alloc+0x25/0x73 [zram]
    zcomp_strm_multi_find+0xe7/0x173 [zram]
    zcomp_strm_find+0xc/0xe [zram]
    zram_bvec_rw+0x2ca/0x7e0 [zram]
    zram_make_request+0x1fa/0x301 [zram]
    generic_make_request+0x9c/0xdb
    submit_bio+0xf7/0x120
    ext4_io_submit+0x2e/0x43
    ext4_bio_write_page+0x1b7/0x300
    mpage_submit_page+0x60/0x77
    mpage_map_and_submit_buffers+0x10f/0x21d
    ext4_writepages+0xc8c/0xe1b
    do_writepages+0x23/0x2c
    __filemap_fdatawrite_range+0x84/0x8b
    filemap_flush+0x1c/0x1e
    ext4_alloc_da_blocks+0xb8/0x117
    ext4_rename+0x132/0x6dc
    ? mark_held_locks+0x5f/0x76
    ext4_rename2+0x29/0x2b
    vfs_rename+0x540/0x636
    SyS_renameat2+0x359/0x44d
    SyS_rename+0x1e/0x20
    entry_SYSCALL_64_fastpath+0x12/0x6f

[minchan@kernel.org: add stable mark]
BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ia928fb8b2e1af1413a602d013efef4e1323900ce
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Kyeongdon Kim <kyeongdon.kim@lge.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 3d5fe03a3ea013060ebba2a811aeb0f23f56aefa)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416645
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/409f66e1e2ce52456ecb438a611ee8c327cc7306/drivers/block/zram/zcomp_lzo.c
[modify] https://crrev.com/409f66e1e2ce52456ecb438a611ee8c327cc7306/drivers/block/zram/zcomp.c
[modify] https://crrev.com/409f66e1e2ce52456ecb438a611ee8c327cc7306/drivers/block/zram/zcomp_lz4.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/585023c09b49e5f64a89b098019308a59b63510e

commit 585023c09b49e5f64a89b098019308a59b63510e
Author: Kyeongdon Kim <kyeongdon.kim@lge.com>
Date: Thu Feb 09 04:31:26 2017

UPSTREAM: zram: try vmalloc() after kmalloc()

When we're using LZ4 multi compression streams for zram swap, we found
out page allocation failure message in system running test.  That was
not only once, but a few(2 - 5 times per test).  Also, some failure
cases were continually occurring to try allocation order 3.

In order to make parallel compression private data, we should call
kzalloc() with order 2/3 in runtime(lzo/lz4).  But if there is no order
2/3 size memory to allocate in that time, page allocation fails.  This
patch makes to use vmalloc() as fallback of kmalloc(), this prevents
page alloc failure warning.

After using this, we never found warning message in running test, also
It could reduce process startup latency about 60-120ms in each case.

For reference a call trace :

    Binder_1: page allocation failure: order:3, mode:0x10c0d0
    CPU: 0 PID: 424 Comm: Binder_1 Tainted: GW 3.10.49-perf-g991d02b-dirty #20
    Call trace:
      dump_backtrace+0x0/0x270
      show_stack+0x10/0x1c
      dump_stack+0x1c/0x28
      warn_alloc_failed+0xfc/0x11c
      __alloc_pages_nodemask+0x724/0x7f0
      __get_free_pages+0x14/0x5c
      kmalloc_order_trace+0x38/0xd8
      zcomp_lz4_create+0x2c/0x38
      zcomp_strm_alloc+0x34/0x78
      zcomp_strm_multi_find+0x124/0x1ec
      zcomp_strm_find+0xc/0x18
      zram_bvec_rw+0x2fc/0x780
      zram_make_request+0x25c/0x2d4
      generic_make_request+0x80/0xbc
      submit_bio+0xa4/0x15c
      __swap_writepage+0x218/0x230
      swap_writepage+0x3c/0x4c
      shrink_page_list+0x51c/0x8d0
      shrink_inactive_list+0x3f8/0x60c
      shrink_lruvec+0x33c/0x4cc
      shrink_zone+0x3c/0x100
      try_to_free_pages+0x2b8/0x54c
      __alloc_pages_nodemask+0x514/0x7f0
      __get_free_pages+0x14/0x5c
      proc_info_read+0x50/0xe4
      vfs_read+0xa0/0x12c
      SyS_read+0x44/0x74
    DMA: 3397*4kB (MC) 26*8kB (RC) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB
         0*512kB 0*1024kB 0*2048kB 0*4096kB = 13796kB

[minchan@kernel.org: change vmalloc gfp and adding comment about gfp]
[sergey.senozhatsky@gmail.com: tweak comments and styles]
BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I0b8e1b52a2e8cef0c983c451601c5e28bd445d8c
Signed-off-by: Kyeongdon Kim <kyeongdon.kim@lge.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit d913897abace843bba20249f3190167f7895e9c3)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416646
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/585023c09b49e5f64a89b098019308a59b63510e/drivers/block/zram/zcomp_lzo.c
[modify] https://crrev.com/585023c09b49e5f64a89b098019308a59b63510e/drivers/block/zram/zcomp_lz4.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b0d1ee5d62e40e0c892f6d46346c38cfdf64eb03

commit b0d1ee5d62e40e0c892f6d46346c38cfdf64eb03
Author: Minchan Kim <minchan@kernel.org>
Date: Thu Feb 09 04:31:27 2017

UPSTREAM: zram: pass gfp from zcomp frontend to backend

Each zcomp backend uses own gfp flag but it's pointless because the
context they could be called is driven by upper layer(ie, zcomp
frontend).  As well, zcomp frondend could call them in different
context.  One context(ie, zram init part) is it should be better to make
sure successful allocation other context(ie, further stream allocation
part for accelarating I/O speed) is just optional so let's pass gfp down
from driver (ie, zcomp frontend) like normal MM convention.

[sergey.senozhatsky@gmail.com: add missing __vmalloc zero and highmem gfps]
BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I39f8b051fd2a2a4dd3261437bc68bb27d9e97994
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 75d8947a36d0c9aedd69118d1f14bf424005c7c2)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416647
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/b0d1ee5d62e40e0c892f6d46346c38cfdf64eb03/drivers/block/zram/zcomp_lzo.c
[modify] https://crrev.com/b0d1ee5d62e40e0c892f6d46346c38cfdf64eb03/drivers/block/zram/zcomp.c
[modify] https://crrev.com/b0d1ee5d62e40e0c892f6d46346c38cfdf64eb03/drivers/block/zram/zcomp.h
[modify] https://crrev.com/b0d1ee5d62e40e0c892f6d46346c38cfdf64eb03/drivers/block/zram/zcomp_lz4.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/bfa7720ab4e40ffd55278b2b46df7f39a3a46930

commit bfa7720ab4e40ffd55278b2b46df7f39a3a46930
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:28 2017

UPSTREAM: zram/zcomp: do not zero out zcomp private pages

Do not __GFP_ZERO allocated zcomp ->private pages.  We keep allocated
streams around and use them for read/write requests, so we supply a
zeroed out ->private to compression algorithm as a scratch buffer only
once -- the first time we use that stream.  For the rest of IO requests
served by this stream ->private usually contains some temporarily data
from the previous requests.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ifda7ac595ab6e46455bd566ae14a4689764bfdb2
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit e02d238c9852a91b30da9ea32ce36d1416cdc683)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416648
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/bfa7720ab4e40ffd55278b2b46df7f39a3a46930/drivers/block/zram/zcomp_lzo.c
[modify] https://crrev.com/bfa7720ab4e40ffd55278b2b46df7f39a3a46930/drivers/block/zram/zcomp_lz4.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b4265dad36e5cb0b2559ff5824c6dd2208c1570b

commit b4265dad36e5cb0b2559ff5824c6dd2208c1570b
Author: YiPing Xu <xuyiping@huawei.com>
Date: Thu Feb 09 04:31:29 2017

UPSTREAM: zsmalloc: drop unused member 'mapping_area->huge'

When unmapping a huge class page in zs_unmap_object, the page will be
unmapped by kmap_atomic.  the "!area->huge" branch in __zs_unmap_object
is alway true, and no code set "area->huge" now, so we can drop it.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I9dce34118d47d3e2d457f066d7a175b8bbc50663
Signed-off-by: YiPing Xu <xuyiping@huawei.com>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit a82cbf07131b56e7e51fbb008b82ef769af08790)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416649
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/b4265dad36e5cb0b2559ff5824c6dd2208c1570b/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/dbfdbd48284d43dcc7aac6f574e4f59e25035848

commit dbfdbd48284d43dcc7aac6f574e4f59e25035848
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:30 2017

UPSTREAM: mm/zsmalloc: add `freeable' column to pool stat

Add a new column to pool stats, which will tell how many pages ideally
can be freed by class compaction, so it will be easier to analyze
zsmalloc fragmentation.

At the moment, we have only numbers of FULL and ALMOST_EMPTY classes,
but they don't tell us how badly the class is fragmented internally.

The new /sys/kernel/debug/zsmalloc/zramX/classes output look as follows:

 class  size almost_full almost_empty obj_allocated   obj_used pages_used pages_per_zspage freeable
[..]
    12   224           0            2           146          5          8                4        4
    13   240           0            0             0          0          0                1        0
    14   256           1           13          1840       1672        115                1       10
    15   272           0            0             0          0          0                1        0
[..]
    49   816           0            3           745        735        149                1        2
    51   848           3            4           361        306         76                4        8
    52   864          12           14           378        268         81                3       21
    54   896           1           12           117         57         26                2       12
    57   944           0            0             0          0          0                3        0
[..]
 Total                26          131         12709      10994       1071                       134

For example, from this particular output we can easily conclude that
class-896 is heavily fragmented -- it occupies 26 pages, 12 can be freed
by compaction.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ied927394003857b84b51adbed04d5f0b3688978d
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 1120ed5483941d9cd2cf52cb9644a4311dbd1011)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416650
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/dbfdbd48284d43dcc7aac6f574e4f59e25035848/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/cfb0a15629780f7cafebc85871c180f8a5dab247

commit cfb0a15629780f7cafebc85871c180f8a5dab247
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:31 2017

UPSTREAM: zsmalloc: use shrinker to trigger auto-compaction

Perform automatic pool compaction by a shrinker when system is getting
tight on memory.

User-space has a very little knowledge regarding zsmalloc fragmentation
and basically has no mechanism to tell whether compaction will result in
any memory gain.  Another issue is that user space is not always aware
of the fact that system is getting tight on memory.  Which leads to very
uncomfortable scenarios when user space may start issuing compaction
'randomly' or from crontab (for example).  Fragmentation is not always
necessarily bad, allocated and unused objects, after all, may be filled
with the data later, w/o the need of allocating a new zspage.  On the
other hand, we obviously don't want to waste memory when the system
needs it.

Compaction now has a relatively quick pool scan so we are able to
estimate the number of pages that will be freed easily, which makes it
possible to call this function from a shrinker->count_objects()
callback.  We also abort compaction as soon as we detect that we can't
free any pages any more, preventing wasteful objects migrations.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ia0822efd96eb977aed489225f7a20b4c9d7b554e
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Suggested-by: Minchan Kim <minchan@kernel.org>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit ab9d306d9c3bf64b1dbad127aa13252cc550f839)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416651
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/cfb0a15629780f7cafebc85871c180f8a5dab247/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6c0ac716127abbc986a327a0429c850742164735

commit 6c0ac716127abbc986a327a0429c850742164735
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:32 2017

UPSTREAM: zsmalloc: partial page ordering within a fullness_list

We want to see more ZS_FULL pages and less ZS_ALMOST_{FULL, EMPTY}
pages.  Put a page with higher ->inuse count first within its
->fullness_list, which will give us better chances to fill up this page
with new objects (find_get_zspage() return ->fullness_list head for new
object allocation), so some zspages will become ZS_ALMOST_FULL/ZS_FULL
quicker.

It performs a trivial and cheap ->inuse compare which does not slow down
zsmalloc and in the worst case keeps the list pages in no particular
order.

A more expensive solution could sort fullness_list by ->inuse count.

[minchan@kernel.org: code adjustments]
BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I6575d96038b69c8bc36aabd3dd9d311d0a838f89
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 58f171174625150f3aaad0cddd3e365270b8e1b8)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416652
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/6c0ac716127abbc986a327a0429c850742164735/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/bf6c91960a9c63fc0ab66dea946dc50ecdfa5cdb

commit bf6c91960a9c63fc0ab66dea946dc50ecdfa5cdb
Author: Minchan Kim <minchan.kim@lge.com>
Date: Thu Feb 09 04:31:33 2017

UPSTREAM: zsmalloc: consider ZS_ALMOST_FULL as migrate source

There is no reason to prevent select ZS_ALMOST_FULL as migration source
if we cannot find source from ZS_ALMOST_EMPTY.

With this patch, zs_can_compact will return more exact result.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I0abe9ed5c19ca78b4793ce24d691fdd798f2f918
Signed-off-by: Minchan Kim <minchan.kim@lge.com>
Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit ad9d5e175a77a253f52a7259a7c918b8351d99f1)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416653
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/bf6c91960a9c63fc0ab66dea946dc50ecdfa5cdb/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e05da43a95a4ccb786ff4f25677742213ded3638

commit e05da43a95a4ccb786ff4f25677742213ded3638
Author: Minchan Kim <minchan@kernel.org>
Date: Thu Feb 09 04:31:34 2017

UPSTREAM: zsmalloc: use class->pages_per_zspage

There is no need to recalcurate pages_per_zspage in runtime.  Just use
class->pages_per_zspage to avoid unnecessary runtime overhead.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ib84c0cb8e003a61d3e8fb896a17faf98f2bc52ed
Signed-off-by: Minchan Kim <minchan@kernel.org>
Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 6cbf16b3b66a61b9c6df8f2ed4ac346cb427f28a)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416654
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/e05da43a95a4ccb786ff4f25677742213ded3638/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/220303f1b9520ef646e2cd119712c4b9d18ef4b2

commit 220303f1b9520ef646e2cd119712c4b9d18ef4b2
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:35 2017

UPSTREAM: zsmalloc: do not take class lock in zs_shrinker_count()

We can avoid taking class ->lock around zs_can_compact() in
zs_shrinker_count(), because the number that we return back is outdated
in general case, by design.  We have different sources that are able to
change class's state right after we return from zs_can_compact() --
ongoing I/O operations, manually triggered compaction, or two of them
happening simultaneously.

We re-do this calculations during compaction on a per class basis
anyway.

zs_unregister_shrinker() will not return until we have an active
shrinker, so classes won't unexpectedly disappear while
zs_shrinker_count() iterates them.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Idfcbbcaaa48799c740c4f2cf983d34a98dd51064
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit b3e237f1f5a86030c875e186ff19640f4f4f3c63)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416655
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/220303f1b9520ef646e2cd119712c4b9d18ef4b2/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c892385604e6e69afc8a6dc240497cb7e938030c

commit c892385604e6e69afc8a6dc240497cb7e938030c
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:36 2017

UPSTREAM: zsmalloc: remove null check from destroy_handle_cache()

We can pass a NULL cache pointer to kmem_cache_destroy(), because it
NULL-checks its argument now.  Remove redundant test from
destroy_handle_cache().

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ieb308eae7d38acedae008accaaf2b5d743d0bfa8
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit cd10add00c1b31cd664a31108a9b395025def50a)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416656
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/c892385604e6e69afc8a6dc240497cb7e938030c/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/d3f3c001337558ddf1e7e8c0aee7ca0aa799e298

commit d3f3c001337558ddf1e7e8c0aee7ca0aa799e298
Author: Hui Zhu <zhuhui@xiaomi.com>
Date: Thu Feb 09 04:31:37 2017

UPSTREAM: zsmalloc: add comments for ->inuse to zspage

[akpm@linux-foundation.org: fix grammar]
BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I6f417260104cb6cbd64dd5022e9a1237c17449fd
Signed-off-by: Hui Zhu <zhuhui@xiaomi.com>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 8f958c98f28d088a1ef3e021ab7aeb59a234b953)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416657
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/d3f3c001337558ddf1e7e8c0aee7ca0aa799e298/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8154b18019e81a49aded18ab98921e69502c879e

commit 8154b18019e81a49aded18ab98921e69502c879e
Author: Hui Zhu <zhuhui@xiaomi.com>
Date: Thu Feb 09 04:31:38 2017

UPSTREAM: zsmalloc: fix obj_to_head use page_private(page) as value but not pointer

In obj_malloc():

	if (!class->huge)
		/* record handle in the header of allocated chunk */
		link->handle = handle;
	else
		/* record handle in first_page->private */
		set_page_private(first_page, handle);

In the hugepage we save handle to private directly.

But in obj_to_head():

	if (class->huge) {
		VM_BUG_ON(!is_first_page(page));
		return *(unsigned long *)page_private(page);
	} else
		return *(unsigned long *)obj;

It is used as a pointer.

The reason why there is no problem until now is huge-class page is born
with ZS_FULL so it can't be migrated.  However, we need this patch for
future work: "VM-aware zsmalloced page migration" to reduce external
fragmentation.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I78fa93b97ede5715728d6c22446681bf87b3254d
Signed-off-by: Hui Zhu <zhuhui@xiaomi.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 12a7bfad58cd604616dd5205efa6dc2be6f299eb)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416658
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/8154b18019e81a49aded18ab98921e69502c879e/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f6debcb93cb6668b3beda1f7b6fde879d8b8b6ff

commit f6debcb93cb6668b3beda1f7b6fde879d8b8b6ff
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Thu Feb 09 04:31:39 2017

UPSTREAM: zsmalloc: use preempt.h for in_interrupt()

A cosmetic change.

Commit c60369f01125 ("staging: zsmalloc: prevent mappping in interrupt
context") added in_interrupt() check to zs_map_object() and 'hardirq.h'
include; but in_interrupt() macro is defined in 'preempt.h' not in
'hardirq.h', so include it instead.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ic77793dc54b528ee7d568e58f37b9a1fd51bb2f6
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 759b26b29885a8ef6101aa554d9990803f6ef792)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416659
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/f6debcb93cb6668b3beda1f7b6fde879d8b8b6ff/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5445a33278211a58c4df73bd168afcffa9c38c1b

commit 5445a33278211a58c4df73bd168afcffa9c38c1b
Author: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Date: Thu Feb 09 04:31:40 2017

UPSTREAM: zsmalloc: don't test shrinker_enabled in zs_shrinker_count()

We don't let user to disable shrinker in zsmalloc (once it's been
enabled), so no need to check ->shrinker_enabled in zs_shrinker_count(),
at the moment at least.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I60e840a424761bde40df4c1e6fd76c2bc835307b
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 2c35169572b84897b43e6f3e9667fd1904451f34)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416660
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/5445a33278211a58c4df73bd168afcffa9c38c1b/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/fe283acdf8cced7b870f20f7393a949fe4da1982

commit fe283acdf8cced7b870f20f7393a949fe4da1982
Author: Hui Zhu <zhuhui@xiaomi.com>
Date: Thu Feb 09 04:31:41 2017

UPSTREAM: mm/zsmalloc.c: remove useless line in obj_free()

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ie9bece3d5179c388a884412b2758a623b1a15ed9
Signed-off-by: Hui Zhu <zhuhui@xiaomi.com>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 6f0b22760b7d8317569252cc7c36cbed22ebe401)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416661
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/fe283acdf8cced7b870f20f7393a949fe4da1982/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/396ef4877a9803978364f78ee77b996c03e429d0

commit 396ef4877a9803978364f78ee77b996c03e429d0
Author: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Date: Thu Feb 09 04:31:42 2017

UPSTREAM: zsmalloc: reduce size_class memory usage

Each `struct size_class' contains `struct zs_size_stat': an array of
NR_ZS_STAT_TYPE `unsigned long'.  For zsmalloc built with no
CONFIG_ZSMALLOC_STAT this results in a waste of `2 * sizeof(unsigned
long)' per-class.

The patch removes unneeded `struct zs_size_stat' members by redefining
NR_ZS_STAT_TYPE (max stat idx in array).

Since both NR_ZS_STAT_TYPE and zs_stat_type are compile time constants,
GCC can eliminate zs_stat_inc()/zs_stat_dec() calls that use zs_stat_type
larger than NR_ZS_STAT_TYPE: CLASS_ALMOST_EMPTY and CLASS_ALMOST_FULL at
the moment.

./scripts/bloat-o-meter mm/zsmalloc.o.old mm/zsmalloc.o.new
add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-39 (-39)
function                                     old     new   delta
fix_fullness_group                            97      94      -3
insert_zspage                                100      86     -14
remove_zspage                                141     119     -22

To summarize:
a) each class now uses less memory
b) we avoid a number of dec/inc stats (a minor optimization,
   but still).

The gain will increase once we introduce additional stats.

A simple IO test.

iozone -t 4 -R -r 32K -s 60M -I +Z
                        patched                 base
"  Initial write "       4145599.06              4127509.75
"        Rewrite "       4146225.94              4223618.50
"           Read "      17157606.00             17211329.50
"        Re-read "      17380428.00             17267650.50
"   Reverse Read "      16742768.00             16162732.75
"    Stride read "      16586245.75             16073934.25
"    Random read "      16349587.50             15799401.75
" Mixed workload "      10344230.62              9775551.50
"   Random write "       4277700.62              4260019.69
"         Pwrite "       4302049.12              4313703.88
"          Pread "       6164463.16              6126536.72
"         Fwrite "       7131195.00              6952586.00
"          Fread "      12682602.25             12619207.50

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ie357f25fd1451dad85679bd398763053bb0e2410
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 6fe5186f0c7c18a8beb6d96c21e2390df7a12375)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416662
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/396ef4877a9803978364f78ee77b996c03e429d0/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e2ca2936ea55b92f5b0d242be926e3b169ce9021

commit e2ca2936ea55b92f5b0d242be926e3b169ce9021
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date: Fri Feb 10 06:50:33 2017

UPSTREAM: zsmalloc: use page->private instead of page->first_page

We are going to rework how compound_head() work. It will not use
page->first_page as we have it now.

The only other user of page->first_page beyond compound pages is
zsmalloc.

Let's use page->private instead of page->first_page here. It occupies
the same storage space.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ia3659521711bf6296b28f840cbad32020c61889a
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 32e7ba1ea1f8d1f0ea4983e768f8b566770a55b3)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416663
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/e2ca2936ea55b92f5b0d242be926e3b169ce9021/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2a7eb5fb793a4a0327e159712c131acf1e286fdf

commit 2a7eb5fb793a4a0327e159712c131acf1e286fdf
Author: Weijie Yang <weijie.yang@samsung.com>
Date: Fri Feb 10 06:50:34 2017

UPSTREAM: zsmalloc: reorganize struct size_class to pack 4 bytes hole

Reoder the pages_per_zspage field in struct size_class which can
eliminate the 4 bytes hole between it and stats field.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I515908c6d90e7d105f4d007faad5477aed5316ce
Signed-off-by: Weijie Yang <weijie.yang@samsung.com>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 7dfa4612204b511c934ca2a0e4f306f9981bd9aa)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416664
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/2a7eb5fb793a4a0327e159712c131acf1e286fdf/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/571a42433c650de66a5a91c4163f4d8597491cc7

commit 571a42433c650de66a5a91c4163f4d8597491cc7
Author: Dan Streetman <ddstreet@ieee.org>
Date: Fri Feb 10 06:50:35 2017

UPSTREAM: zpool: add zpool_has_pool()

This series makes creation of the zpool and compressor dynamic, so that
they can be changed at runtime.  This makes using/configuring zswap
easier, as before this zswap had to be configured at boot time, using boot
params.

This uses a single list to track both the zpool and compressor together,
although Seth had mentioned an alternative which is to track the zpools
and compressors using separate lists.  In the most common case, only a
single zpool and single compressor, using one list is slightly simpler
than using two lists, and for the uncommon case of multiple zpools and/or
compressors, using one list is slightly less simple (and uses slightly
more memory, probably) than using two lists.

This patch (of 4):

Add zpool_has_pool() function, indicating if the specified type of zpool
is available (i.e.  zsmalloc or zbud).  This allows checking if a pool is
available, without actually trying to allocate it, similar to
crypto_has_alg().

This is used by a following patch to zswap that enables the dynamic
runtime creation of zswap zpools.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ia00c8ef9a2556acf5e162ad503b8da044208c1ce
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Acked-by: Seth Jennings <sjennings@variantweb.net>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 3f0e131221eb951c45c93d1cce9db73889be2a5e)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416665
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/571a42433c650de66a5a91c4163f4d8597491cc7/mm/zpool.c
[modify] https://crrev.com/571a42433c650de66a5a91c4163f4d8597491cc7/include/linux/zpool.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e3041583c4bd2ba05634f00b9707293ada5aeb5d

commit e3041583c4bd2ba05634f00b9707293ada5aeb5d
Author: Dan Streetman <ddstreet@ieee.org>
Date: Fri Feb 10 06:50:36 2017

UPSTREAM: zpool: change pr_info to pr_debug

Change the pr_info() calls to pr_debug().  There's no need for the extra
verbosity in the log.  Also change the msg formats to be consistent.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I24fd10a7413f3f507dd6fde666b6529ea8193c58
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Ganesh Mahendran <opensource.ganesh@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit cf41f5f496d68f2ced1fc77871c63d1c526fa100)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416666
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/e3041583c4bd2ba05634f00b9707293ada5aeb5d/mm/zpool.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e04e7c97023e1b1b835d43b199a434e316973b8a

commit e04e7c97023e1b1b835d43b199a434e316973b8a
Author: Dan Streetman <ddstreet@ieee.org>
Date: Fri Feb 10 06:50:37 2017

UPSTREAM: zpool: remove redundant zpool->type string, const-ify zpool_get_type

Make the return type of zpool_get_type const; the string belongs to the
zpool driver and should not be modified.  Remove the redundant type field
in the struct zpool; it is private to zpool.c and isn't needed since
->driver->type can be used directly.  Add comments indicating strings must
be null-terminated.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I2ec0145d848ba2fa179aa0808376fbfcaffb0f4a
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Seth Jennings <sjennings@variantweb.net>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 69e18f4dbedfbf208452e9da9979c92da30d2442)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416667
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/e04e7c97023e1b1b835d43b199a434e316973b8a/mm/zpool.c
[modify] https://crrev.com/e04e7c97023e1b1b835d43b199a434e316973b8a/include/linux/zpool.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/90403974378ad603d80b48b0e02a22652b3196fb

commit 90403974378ad603d80b48b0e02a22652b3196fb
Author: Minchan Kim <minchan@kernel.org>
Date: Fri Feb 10 06:50:38 2017

UPSTREAM: zsmalloc: use first_page rather than page

Clean up function parameter "struct page".  Many functions of zsmalloc
expect that page paramter is "first_page" so use "first_page" rather
than "page" for code readability.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I556ef70a8541992c4ff11904752080c47cc416f2
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit a42094676f076534bf4998625456fe0bb99c1f1e)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416668
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/90403974378ad603d80b48b0e02a22652b3196fb/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/465af27fe86247175c1fa084f51dcb3332d4bda2

commit 465af27fe86247175c1fa084f51dcb3332d4bda2
Author: Minchan Kim <minchan@kernel.org>
Date: Fri Feb 10 06:50:39 2017

UPSTREAM: zsmalloc: clean up many BUG_ON

There are many BUG_ON in zsmalloc.c which is not recommened so change
them as alternatives.

Normal rule is as follows:

1. avoid BUG_ON if possible. Instead, use VM_BUG_ON or VM_BUG_ON_PAGE

2. use VM_BUG_ON_PAGE if we need to see struct page's fields

3. use those assertion in primitive functions so higher functions can
   rely on the assertion in the primitive function.

4. Don't use assertion if following instruction can trigger Oops

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Id96d1377124de40b6c8e5249110624712b0e2307
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 830e4bc5baa9fda5d45257e9a3dbb3555c6c180e)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416669
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/465af27fe86247175c1fa084f51dcb3332d4bda2/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4671fdde923f84fd7f10bd58de965a9e4bbc20f3

commit 4671fdde923f84fd7f10bd58de965a9e4bbc20f3
Author: Sergey SENOZHATSKY <sergey.senozhatsky@gmail.com>
Date: Fri Feb 10 06:50:40 2017

UPSTREAM: mm: zsmalloc: constify struct zs_pool name

Constify `struct zs_pool' ->name.

[akpm@inux-foundation.org: constify zpool_create_pool()'s `type' arg also]
BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I1a21fdd572edd75275071e64ac86a6bf6ef4140b
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Dan Streetman <ddstreet@ieee.org>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 6f3526d6db7cbe8b53e42d6bf0cad2072afcf3fe)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416670
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/4671fdde923f84fd7f10bd58de965a9e4bbc20f3/mm/zsmalloc.c
[modify] https://crrev.com/4671fdde923f84fd7f10bd58de965a9e4bbc20f3/mm/zpool.c
[modify] https://crrev.com/4671fdde923f84fd7f10bd58de965a9e4bbc20f3/include/linux/zpool.h
[modify] https://crrev.com/4671fdde923f84fd7f10bd58de965a9e4bbc20f3/mm/zbud.c
[modify] https://crrev.com/4671fdde923f84fd7f10bd58de965a9e4bbc20f3/include/linux/zsmalloc.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/fd8323c526e814c17d6deac8efcd3f8b057ddc94

commit fd8323c526e814c17d6deac8efcd3f8b057ddc94
Author: Minchan Kim <minchan@kernel.org>
Date: Fri Feb 10 06:50:41 2017

UPSTREAM: zsmalloc: reorder function parameters

Clean up function parameter ordering to order higher data structure
first.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: Ib90ca9a7e25c7d3f6c45dfed96d82db26d79dffd
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 251cbb951b831acd8451d75b40696834f07c29c5)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416671
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/fd8323c526e814c17d6deac8efcd3f8b057ddc94/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7ca02462c5d6122c40fc8c8e2f57c98b5a1eaec4

commit 7ca02462c5d6122c40fc8c8e2f57c98b5a1eaec4
Author: Minchan Kim <minchan@kernel.org>
Date: Fri Feb 10 06:50:42 2017

UPSTREAM: zsmalloc: remove unused pool param in obj_free

Let's remove unused pool param in obj_free

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I9bf05d1b1d9d8b6f9cdb707f4146b58c09e6c523
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 1ee4716585ed80b7917ba3c5aa38e5e0d677d583)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416672
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/7ca02462c5d6122c40fc8c8e2f57c98b5a1eaec4/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/55f8cae63c7c17830b092371677bd7e1a5372150

commit 55f8cae63c7c17830b092371677bd7e1a5372150
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Fri Feb 10 06:50:43 2017

UPSTREAM: zsmalloc: require GFP in zs_malloc()

Pass GFP flags to zs_malloc() instead of using a fixed mask supplied to
zs_create_pool(), so we can be more flexible, but, more importantly, we
need this to switch zram to per-cpu compression streams -- zram will try
to allocate handle with preemption disabled in a fast path and switch to
a slow path (using different gfp mask) if the fast one has failed.

Apart from that, this also align zs_malloc() interface with zspool/zbud.

[sergey.senozhatsky@gmail.com: pass GFP flags to zs_malloc() instead of using a fixed mask]
  Link: http://lkml.kernel.org/r/20160429150942.GA637@swordfish
Link: http://lkml.kernel.org/r/20160429150942.GA637@swordfish
BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I06672f48b8f1ec07bfaa1ce0912dcfdb724a6732
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit d0d8da2dc49dfdfe1d788eaf4d55eb5d4964d926)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416673
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/55f8cae63c7c17830b092371677bd7e1a5372150/mm/zsmalloc.c
[modify] https://crrev.com/55f8cae63c7c17830b092371677bd7e1a5372150/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/55f8cae63c7c17830b092371677bd7e1a5372150/include/linux/zsmalloc.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/be688adcd02f9f57b0a242d540607c6a6ceee127

commit be688adcd02f9f57b0a242d540607c6a6ceee127
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Fri Feb 10 06:50:45 2017

BACKPORT: zram: user per-cpu compression streams

Remove idle streams list and keep compression streams in per-cpu data.
This removes two contented spin_lock()/spin_unlock() calls from write
path and also prevent write OP from being preempted while holding the
compression stream, which can cause slow downs.

For instance, let's assume that we have N cpus and N-2
max_comp_streams.TASK1 owns the last idle stream, TASK2-TASK3 come in
with the write requests:

  TASK1            TASK2              TASK3
 zram_bvec_write()
  spin_lock
  find stream
  spin_unlock

  compress

  <<preempted>>   zram_bvec_write()
                   spin_lock
                   find stream
                   spin_unlock
                     no_stream
                       schedule
                                     zram_bvec_write()
                                      spin_lock
                                      find_stream
                                      spin_unlock
                                        no_stream
                                          schedule
   spin_lock
   release stream
   spin_unlock
     wake up TASK2

not only TASK2 and TASK3 will not get the stream, TASK1 will be
preempted in the middle of its operation; while we would prefer it to
finish compression and release the stream.

Test environment: x86_64, 4 CPU box, 3G zram, lzo

The following fio tests were executed:
      read, randread, write, randwrite, rw, randrw
with the increasing number of jobs from 1 to 10.

                  4 streams        8 streams       per-cpu
  ===========================================================
  jobs1
  READ:           2520.1MB/s       2566.5MB/s      2491.5MB/s
  READ:           2102.7MB/s       2104.2MB/s      2091.3MB/s
  WRITE:          1355.1MB/s       1320.2MB/s      1378.9MB/s
  WRITE:          1103.5MB/s       1097.2MB/s      1122.5MB/s
  READ:           434013KB/s       435153KB/s      439961KB/s
  WRITE:          433969KB/s       435109KB/s      439917KB/s
  READ:           403166KB/s       405139KB/s      403373KB/s
  WRITE:          403223KB/s       405197KB/s      403430KB/s
  jobs2
  READ:           7958.6MB/s       8105.6MB/s      8073.7MB/s
  READ:           6864.9MB/s       6989.8MB/s      7021.8MB/s
  WRITE:          2438.1MB/s       2346.9MB/s      3400.2MB/s
  WRITE:          1994.2MB/s       1990.3MB/s      2941.2MB/s
  READ:           981504KB/s       973906KB/s      1018.8MB/s
  WRITE:          981659KB/s       974060KB/s      1018.1MB/s
  READ:           937021KB/s       938976KB/s      987250KB/s
  WRITE:          934878KB/s       936830KB/s      984993KB/s
  jobs3
  READ:           13280MB/s        13553MB/s       13553MB/s
  READ:           11534MB/s        11785MB/s       11755MB/s
  WRITE:          3456.9MB/s       3469.9MB/s      4810.3MB/s
  WRITE:          3029.6MB/s       3031.6MB/s      4264.8MB/s
  READ:           1363.8MB/s       1362.6MB/s      1448.9MB/s
  WRITE:          1361.9MB/s       1360.7MB/s      1446.9MB/s
  READ:           1309.4MB/s       1310.6MB/s      1397.5MB/s
  WRITE:          1307.4MB/s       1308.5MB/s      1395.3MB/s
  jobs4
  READ:           20244MB/s        20177MB/s       20344MB/s
  READ:           17886MB/s        17913MB/s       17835MB/s
  WRITE:          4071.6MB/s       4046.1MB/s      6370.2MB/s
  WRITE:          3608.9MB/s       3576.3MB/s      5785.4MB/s
  READ:           1824.3MB/s       1821.6MB/s      1997.5MB/s
  WRITE:          1819.8MB/s       1817.4MB/s      1992.5MB/s
  READ:           1765.7MB/s       1768.3MB/s      1937.3MB/s
  WRITE:          1767.5MB/s       1769.1MB/s      1939.2MB/s
  jobs5
  READ:           18663MB/s        18986MB/s       18823MB/s
  READ:           16659MB/s        16605MB/s       16954MB/s
  WRITE:          3912.4MB/s       3888.7MB/s      6126.9MB/s
  WRITE:          3506.4MB/s       3442.5MB/s      5519.3MB/s
  READ:           1798.2MB/s       1746.5MB/s      1935.8MB/s
  WRITE:          1792.7MB/s       1740.7MB/s      1929.1MB/s
  READ:           1727.6MB/s       1658.2MB/s      1917.3MB/s
  WRITE:          1726.5MB/s       1657.2MB/s      1916.6MB/s
  jobs6
  READ:           21017MB/s        20922MB/s       21162MB/s
  READ:           19022MB/s        19140MB/s       18770MB/s
  WRITE:          3968.2MB/s       4037.7MB/s      6620.8MB/s
  WRITE:          3643.5MB/s       3590.2MB/s      6027.5MB/s
  READ:           1871.8MB/s       1880.5MB/s      2049.9MB/s
  WRITE:          1867.8MB/s       1877.2MB/s      2046.2MB/s
  READ:           1755.8MB/s       1710.3MB/s      1964.7MB/s
  WRITE:          1750.5MB/s       1705.9MB/s      1958.8MB/s
  jobs7
  READ:           21103MB/s        20677MB/s       21482MB/s
  READ:           18522MB/s        18379MB/s       19443MB/s
  WRITE:          4022.5MB/s       4067.4MB/s      6755.9MB/s
  WRITE:          3691.7MB/s       3695.5MB/s      5925.6MB/s
  READ:           1841.5MB/s       1933.9MB/s      2090.5MB/s
  WRITE:          1842.7MB/s       1935.3MB/s      2091.9MB/s
  READ:           1832.4MB/s       1856.4MB/s      1971.5MB/s
  WRITE:          1822.3MB/s       1846.2MB/s      1960.6MB/s
  jobs8
  READ:           20463MB/s        20194MB/s       20862MB/s
  READ:           18178MB/s        17978MB/s       18299MB/s
  WRITE:          4085.9MB/s       4060.2MB/s      7023.8MB/s
  WRITE:          3776.3MB/s       3737.9MB/s      6278.2MB/s
  READ:           1957.6MB/s       1944.4MB/s      2109.5MB/s
  WRITE:          1959.2MB/s       1946.2MB/s      2111.4MB/s
  READ:           1900.6MB/s       1885.7MB/s      2082.1MB/s
  WRITE:          1896.2MB/s       1881.4MB/s      2078.3MB/s
  jobs9
  READ:           19692MB/s        19734MB/s       19334MB/s
  READ:           17678MB/s        18249MB/s       17666MB/s
  WRITE:          4004.7MB/s       4064.8MB/s      6990.7MB/s
  WRITE:          3724.7MB/s       3772.1MB/s      6193.6MB/s
  READ:           1953.7MB/s       1967.3MB/s      2105.6MB/s
  WRITE:          1953.4MB/s       1966.7MB/s      2104.1MB/s
  READ:           1860.4MB/s       1897.4MB/s      2068.5MB/s
  WRITE:          1858.9MB/s       1895.9MB/s      2066.8MB/s
  jobs10
  READ:           19730MB/s        19579MB/s       19492MB/s
  READ:           18028MB/s        18018MB/s       18221MB/s
  WRITE:          4027.3MB/s       4090.6MB/s      7020.1MB/s
  WRITE:          3810.5MB/s       3846.8MB/s      6426.8MB/s
  READ:           1956.1MB/s       1994.6MB/s      2145.2MB/s
  WRITE:          1955.9MB/s       1993.5MB/s      2144.8MB/s
  READ:           1852.8MB/s       1911.6MB/s      2075.8MB/s
  WRITE:          1855.7MB/s       1914.6MB/s      2078.1MB/s

perf stat

                                  4 streams                       8 streams                       per-cpu
  ====================================================================================================================
  jobs1
  stalled-cycles-frontend      23,174,811,209 (  38.21%)     23,220,254,188 (  38.25%)       23,061,406,918 (  38.34%)
  stalled-cycles-backend       11,514,174,638 (  18.98%)     11,696,722,657 (  19.27%)       11,370,852,810 (  18.90%)
  instructions                 73,925,005,782 (    1.22)     73,903,177,632 (    1.22)       73,507,201,037 (    1.22)
  branches                     14,455,124,835 ( 756.063)     14,455,184,779 ( 755.281)       14,378,599,509 ( 758.546)
  branch-misses                    69,801,336 (   0.48%)         80,225,529 (   0.55%)           72,044,726 (   0.50%)
  jobs2
  stalled-cycles-frontend      49,912,741,782 (  46.11%)     50,101,189,290 (  45.95%)       32,874,195,633 (  35.11%)
  stalled-cycles-backend       27,080,366,230 (  25.02%)     27,949,970,232 (  25.63%)       16,461,222,706 (  17.58%)
  instructions                122,831,629,690 (    1.13)    122,919,846,419 (    1.13)      121,924,786,775 (    1.30)
  branches                     23,725,889,239 ( 692.663)     23,733,547,140 ( 688.062)       23,553,950,311 ( 794.794)
  branch-misses                    90,733,041 (   0.38%)         96,320,895 (   0.41%)           84,561,092 (   0.36%)
  jobs3
  stalled-cycles-frontend      66,437,834,608 (  45.58%)     63,534,923,344 (  43.69%)       42,101,478,505 (  33.19%)
  stalled-cycles-backend       34,940,799,661 (  23.97%)     34,774,043,148 (  23.91%)       21,163,324,388 (  16.68%)
  instructions                171,692,121,862 (    1.18)    171,775,373,044 (    1.18)      170,353,542,261 (    1.34)
  branches                     32,968,962,622 ( 628.723)     32,987,739,894 ( 630.512)       32,729,463,918 ( 717.027)
  branch-misses                   111,522,732 (   0.34%)        110,472,894 (   0.33%)           99,791,291 (   0.30%)
  jobs4
  stalled-cycles-frontend      98,741,701,675 (  49.72%)     94,797,349,965 (  47.59%)       54,535,655,381 (  33.53%)
  stalled-cycles-backend       54,642,609,615 (  27.51%)     55,233,554,408 (  27.73%)       27,882,323,541 (  17.14%)
  instructions                220,884,807,851 (    1.11)    220,930,887,273 (    1.11)      218,926,845,851 (    1.35)
  branches                     42,354,518,180 ( 592.105)     42,362,770,587 ( 590.452)       41,955,552,870 ( 716.154)
  branch-misses                   138,093,449 (   0.33%)        131,295,286 (   0.31%)          121,794,771 (   0.29%)
  jobs5
  stalled-cycles-frontend     116,219,747,212 (  48.14%)    110,310,397,012 (  46.29%)       66,373,082,723 (  33.70%)
  stalled-cycles-backend       66,325,434,776 (  27.48%)     64,157,087,914 (  26.92%)       32,999,097,299 (  16.76%)
  instructions                270,615,008,466 (    1.12)    270,546,409,525 (    1.14)      268,439,910,948 (    1.36)
  branches                     51,834,046,557 ( 599.108)     51,811,867,722 ( 608.883)       51,412,576,077 ( 729.213)
  branch-misses                   158,197,086 (   0.31%)        142,639,805 (   0.28%)          133,425,455 (   0.26%)
  jobs6
  stalled-cycles-frontend     138,009,414,492 (  48.23%)    139,063,571,254 (  48.80%)       75,278,568,278 (  32.80%)
  stalled-cycles-backend       79,211,949,650 (  27.68%)     79,077,241,028 (  27.75%)       37,735,797,899 (  16.44%)
  instructions                319,763,993,731 (    1.12)    319,937,782,834 (    1.12)      316,663,600,784 (    1.38)
  branches                     61,219,433,294 ( 595.056)     61,250,355,540 ( 598.215)       60,523,446,617 ( 733.706)
  branch-misses                   169,257,123 (   0.28%)        154,898,028 (   0.25%)          141,180,587 (   0.23%)
  jobs7
  stalled-cycles-frontend     162,974,812,119 (  49.20%)    159,290,061,987 (  48.43%)       88,046,641,169 (  33.21%)
  stalled-cycles-backend       92,223,151,661 (  27.84%)     91,667,904,406 (  27.87%)       44,068,454,971 (  16.62%)
  instructions                369,516,432,430 (    1.12)    369,361,799,063 (    1.12)      365,290,380,661 (    1.38)
  branches                     70,795,673,950 ( 594.220)     70,743,136,124 ( 597.876)       69,803,996,038 ( 732.822)
  branch-misses                   181,708,327 (   0.26%)        165,767,821 (   0.23%)          150,109,797 (   0.22%)
  jobs8
  stalled-cycles-frontend     185,000,017,027 (  49.30%)    182,334,345,473 (  48.37%)       99,980,147,041 (  33.26%)
  stalled-cycles-backend      105,753,516,186 (  28.18%)    107,937,830,322 (  28.63%)       51,404,177,181 (  17.10%)
  instructions                418,153,161,055 (    1.11)    418,308,565,828 (    1.11)      413,653,475,581 (    1.38)
  branches                     80,035,882,398 ( 592.296)     80,063,204,510 ( 589.843)       79,024,105,589 ( 730.530)
  branch-misses                   199,764,528 (   0.25%)        177,936,926 (   0.22%)          160,525,449 (   0.20%)
  jobs9
  stalled-cycles-frontend     210,941,799,094 (  49.63%)    204,714,679,254 (  48.55%)      114,251,113,756 (  33.96%)
  stalled-cycles-backend      122,640,849,067 (  28.85%)    122,188,553,256 (  28.98%)       58,360,041,127 (  17.35%)
  instructions                468,151,025,415 (    1.10)    467,354,869,323 (    1.11)      462,665,165,216 (    1.38)
  branches                     89,657,067,510 ( 585.628)     89,411,550,407 ( 588.990)       88,360,523,943 ( 730.151)
  branch-misses                   218,292,301 (   0.24%)        191,701,247 (   0.21%)          178,535,678 (   0.20%)
  jobs10
  stalled-cycles-frontend     233,595,958,008 (  49.81%)    227,540,615,689 (  49.11%)      160,341,979,938 (  43.07%)
  stalled-cycles-backend      136,153,676,021 (  29.03%)    133,635,240,742 (  28.84%)       65,909,135,465 (  17.70%)
  instructions                517,001,168,497 (    1.10)    516,210,976,158 (    1.11)      511,374,038,613 (    1.37)
  branches                     98,911,641,329 ( 585.796)     98,700,069,712 ( 591.583)       97,646,761,028 ( 728.712)
  branch-misses                   232,341,823 (   0.23%)        199,256,308 (   0.20%)          183,135,268 (   0.19%)

per-cpu streams tend to cause significantly less stalled cycles; execute
less branches and hit less branch-misses.

perf stat reported execution time

                          4 streams        8 streams       per-cpu
  ====================================================================
  jobs1
  seconds elapsed        20.909073870     20.875670495    20.817838540
  jobs2
  seconds elapsed        18.529488399     18.720566469    16.356103108
  jobs3
  seconds elapsed        18.991159531     18.991340812    16.766216066
  jobs4
  seconds elapsed        19.560643828     19.551323547    16.246621715
  jobs5
  seconds elapsed        24.746498464     25.221646740    20.696112444
  jobs6
  seconds elapsed        28.258181828     28.289765505    22.885688857
  jobs7
  seconds elapsed        32.632490241     31.909125381    26.272753738
  jobs8
  seconds elapsed        35.651403851     36.027596308    29.108024711
  jobs9
  seconds elapsed        40.569362365     40.024227989    32.898204012
  jobs10
  seconds elapsed        44.673112304     43.874898137    35.632952191

Please see
  Link: http://marc.info/?l=linux-kernel&m=146166970727530
  Link: http://marc.info/?l=linux-kernel&m=146174716719650
for more test results (under low memory conditions).

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I70c29d84c6547cf7ace629bd246d09d607cd104b
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Suggested-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[SR: removed use of __GFP_KSWAPD_RECLAIM which isn't present in 3.18]
(cherry picked from commit da9556a2367cf2261ab4d3e100693c82fb1ddb26)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416674
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/be688adcd02f9f57b0a242d540607c6a6ceee127/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/be688adcd02f9f57b0a242d540607c6a6ceee127/drivers/block/zram/zcomp.c
[modify] https://crrev.com/be688adcd02f9f57b0a242d540607c6a6ceee127/drivers/block/zram/zcomp.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a6a40d39f136a0887c9b49afdacf687f96d2c20a

commit a6a40d39f136a0887c9b49afdacf687f96d2c20a
Author: Dan Streetman <ddstreet@ieee.org>
Date: Fri Feb 10 06:50:46 2017

UPSTREAM: mm/zsmalloc: don't fail if can't create debugfs info

Change the return type of zs_pool_stat_create() to void, and remove the
logic to abort pool creation if the stat debugfs dir/file could not be
created.

The debugfs stat file is for debugging/information only, and doesn't
affect operation of zsmalloc; there is no reason to abort creating the
pool if the stat file can't be created.  This was seen with zswap, which
used the same name for all pool creations, which caused zsmalloc to fail
to create a second pool for zswap if CONFIG_ZSMALLOC_STAT was enabled.

BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I8cdb0efd5b03184dafad13e90a3607b905612686
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Dan Streetman <dan.streetman@canonical.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit d34f615720d17c49b6779f6fcd5cb7eb82231a38)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416675
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/a6a40d39f136a0887c9b49afdacf687f96d2c20a/mm/zsmalloc.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/17b1cb3da98a152a755db3dee3381c7b92f115ab

commit 17b1cb3da98a152a755db3dee3381c7b92f115ab
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Fri Feb 10 06:50:47 2017

BACKPORT: zram: remove max_comp_streams internals

Remove the internal part of max_comp_streams interface, since we
switched to per-cpu streams.  We will keep RW max_comp_streams attr
around, because:

a) we may (silently) switch back to idle compression streams list and
   don't want to disturb user space

b) max_comp_streams attr must wait for the next 'lay off cycle'; we
   give user space 2 years to adjust before we remove/downgrade the attr,
   and there are already several attrs scheduled for removal in 4.11, so
   it's too late for max_comp_streams.

This slightly change a user visible behaviour:

- First, reading from max_comp_stream file now will always return the
  number of online CPUs.

- Second, writing to max_comp_stream will not take any effect.

BUG=chromium:670864
TEST=build/boot elm

Link: http://lkml.kernel.org/r/20160503165546.25201-1-sergey.senozhatsky@gmail.com
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 43209ea2d17aae1540d4e28274e36404f72702f2)
[SR: fix up conflict against chromium specific code]
 Conflicts:
	drivers/block/zram/zram_drv.h
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>

Change-Id: Iaadf9be12915a9109406eeb0de56deb9da87717a
Reviewed-on: https://chromium-review.googlesource.com/416676
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>

[modify] https://crrev.com/17b1cb3da98a152a755db3dee3381c7b92f115ab/drivers/block/zram/zram_drv.h
[modify] https://crrev.com/17b1cb3da98a152a755db3dee3381c7b92f115ab/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/17b1cb3da98a152a755db3dee3381c7b92f115ab/drivers/block/zram/zcomp.c
[modify] https://crrev.com/17b1cb3da98a152a755db3dee3381c7b92f115ab/Documentation/blockdev/zram.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/447f9d26947aa13cd6dfc1a9d51f20cb869729e4

commit 447f9d26947aa13cd6dfc1a9d51f20cb869729e4
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Fri Feb 10 06:50:48 2017

UPSTREAM: zram: introduce per-device debug_stat sysfs node

debug_stat sysfs is read-only and represents various debugging data that
zram developers may need.  This file is not meant to be used by anyone
else: its content is not documented and will change any time w/o any
notice.  Therefore, the output of debug_stat file contains a version
string.  To avoid any confusion, we will increase the version number
every time we modify the output.

At the moment this file exports only one value -- the number of
re-compressions, IOW, the number of times compression fast path has
failed.  This stat is temporary any will be useful in case if any
per-cpu compression streams regressions will be reported.

Link: http://lkml.kernel.org/r/20160513230834.GB26763@bbox
Link: http://lkml.kernel.org/r/20160511134553.12655-1-sergey.senozhatsky@gmail.com
BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I60e07b669dd700399d3f9235e0c58f0d3b5b1e78
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 623e47fc64f8de480b322b7ed68855f97137e2a5)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416677
Reviewed-by: Cheng-Yu Lee <cylee@chromium.org>

[modify] https://crrev.com/447f9d26947aa13cd6dfc1a9d51f20cb869729e4/Documentation/ABI/testing/sysfs-block-zram
[modify] https://crrev.com/447f9d26947aa13cd6dfc1a9d51f20cb869729e4/drivers/block/zram/zram_drv.h
[modify] https://crrev.com/447f9d26947aa13cd6dfc1a9d51f20cb869729e4/drivers/block/zram/zram_drv.c
[modify] https://crrev.com/447f9d26947aa13cd6dfc1a9d51f20cb869729e4/Documentation/blockdev/zram.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c0cf8ff05fec4d2a7700499f93c1846813af4c50

commit c0cf8ff05fec4d2a7700499f93c1846813af4c50
Author: Dan Streetman <ddstreet@ieee.org>
Date: Fri Feb 10 06:50:49 2017

UPSTREAM: update "mm/zsmalloc: don't fail if can't create debugfs info"

Some updates to commit d34f615720d1 ("mm/zsmalloc: don't fail if can't
create debugfs info"):

 - add pr_warn to all stat failure cases
 - do not prevent module loading on stat failure

Link: http://lkml.kernel.org/r/1463671123-5479-1-git-send-email-ddstreet@ieee.org
BUG=chromium:670864
TEST=build/boot on elm

Change-Id: I92d89c09678071b532822db67449a4fdef6b5ba7
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Reviewed-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Dan Streetman <dan.streetman@canonical.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 4abaac9b733ea44fcf0d561ec1813e0394e61c9d)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416678

[modify] https://crrev.com/c0cf8ff05fec4d2a7700499f93c1846813af4c50/mm/zsmalloc.c

Everything has landed on 3.18.

...is there interest in trying to get any of this done on 3.14 or 3.10, or 3.8 or should we close this?

Not sure if we want to try to pull back to 3.14 -- I don't have cycles to do it right now, so I think we should close.

I compared the tab switching time with R57 Caroline as the baseline against ToT R58 which contains the patches. With 96 tabs the memory footprint is about 8.5GB. The patches provide significant speedup as the tab switching time for R57 is 488 ms while R58 is 320ms.