Merge branch 'akpm' (patches from Andrew)

		The mm_stat file is read-only and represents device's mm

		statistics (orig_data_size, compr_data_size, etc.) in a format

		similar to block layer statistics file format.

What:		/sys/block/zram<id>/debug_stat

Date:		July 2016

Contact:	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>

Description:

		The debug_stat file is read-only and represents various

		device's debugging info useful for kernel developers. Its

		format is not documented intentionally and may change

		anytime without any notice.

pre-created. Default: 1.

2) Set max number of compression streams

	Compression backend may use up to max_comp_streams compression streams,

	thus allowing up to max_comp_streams concurrent compression operations.

	By default, compression backend uses single compression stream.

	Examples:

	#show max compression streams number

	Regardless the value passed to this attribute, ZRAM will always

	allocate multiple compression streams - one per online CPUs - thus

	allowing several concurrent compression operations. The number of

	allocated compression streams goes down when some of the CPUs

	become offline. There is no single-compression-stream mode anymore,

	unless you are running a UP system or has only 1 CPU online.

	To find out how many streams are currently available:

	cat /sys/block/zram0/max_comp_streams

	#set max compression streams number to 3

	echo 3 > /sys/block/zram0/max_comp_streams

Note:

In order to enable compression backend's multi stream support max_comp_streams

must be initially set to desired concurrency level before ZRAM device

initialisation. Once the device initialised as a single stream compression

backend (max_comp_streams equals to 1), you will see error if you try to change

the value of max_comp_streams because single stream compression backend

implemented as a special case by lock overhead issue and does not support

dynamic max_comp_streams. Only multi stream backend supports dynamic

max_comp_streams adjustment.

3) Select compression algorithm

	Using comp_algorithm device attribute one can see available and

	currently selected (shown in square brackets) compression algorithms,

pages_compacted   RO    the number of pages freed during compaction

                        (available only via zram<id>/mm_stat node)

compact           WO    trigger memory compaction

debug_stat        RO    this file is used for zram debugging purposes

WARNING

=======

 TracerPid                   PID of process tracing this process (0 if not)

 Uid                         Real, effective, saved set, and  file system UIDs

 Gid                         Real, effective, saved set, and  file system GIDs

 Umask                       file mode creation mask

 FDSize                      number of file descriptor slots currently allocated

 Groups                      supplementary group list

 NStgid                      descendant namespace thread group ID hierarchy

== Graceful fallback ==

Code walking pagetables but unware about huge pmds can simply call

Code walking pagetables but unaware about huge pmds can simply call

split_huge_pmd(vma, pmd, addr) where the pmd is the one returned by

pmd_offset. It's trivial to make the code transparent hugepage aware

by just grepping for "pmd_offset" and adding split_huge_pmd where

map/unmap of the whole compound page.

We set PG_double_map when a PMD of the page got split for the first time,

but still have PMD mapping. The addtional references go away with last

but still have PMD mapping. The additional references go away with last

compound_mapcount.

split_huge_page internally has to distribute the refcounts in the head

We safe against physical memory scanners too: the only legitimate way

scanner can get reference to a page is get_page_unless_zero().

All tail pages has zero ->_refcount until atomic_add(). It prevent scanner

from geting reference to tail page up to the point. After the atomic_add()

we don't care about ->_refcount value.  We already known how many references

with should uncharge from head page.

All tail pages have zero ->_refcount until atomic_add(). This prevents the

scanner from getting a reference to the tail page up to that point. After the

atomic_add() we don't care about the ->_refcount value.  We already known how

many references should be uncharged from the head page.

For head page get_page_unless_zero() will succeed and we don't mind. It's

clear where reference should go after split: it will stay on head page.

z3fold

------

z3fold is a special purpose allocator for storing compressed pages.

It is designed to store up to three compressed pages per physical page.

It is a zbud derivative which allows for higher compression

ratio keeping the simplicity and determinism of its predecessor.

The main differences between z3fold and zbud are:

* unlike zbud, z3fold allows for up to PAGE_SIZE allocations

* z3fold can hold up to 3 compressed pages in its page

* z3fold doesn't export any API itself and is thus intended to be used

  via the zpool API.

To keep the determinism and simplicity, z3fold, just like zbud, always

stores an integral number of compressed pages per page, but it can store

up to 3 pages unlike zbud which can store at most 2. Therefore the

compression ratio goes to around 2.7x while zbud's one is around 1.7x.

Unlike zbud (but like zsmalloc for that matter) z3fold_alloc() does not

return a dereferenceable pointer. Instead, it returns an unsigned long

handle which encodes actual location of the allocated object.

Keeping effective compression ratio close to zsmalloc's, z3fold doesn't

depend on MMU enabled and provides more predictable reclaim behavior

which makes it a better fit for small and response-critical systems.