zram: Disable allocation failure logging

Disable the logging of errors when allocations fail
for zram pages. This avoid excessive logging when system is
very low on memory.

Change-Id: Ifabcf8f1b9c3e3717599d6a0a924f7b2061f00ea
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
zram: Change ratio to 90% for bad compress

Change the ratio for determining whether or not we should store
pages as uncompressed in zram. This will allow zram to fit more
data since more of the pages will be stored as compressed.

Change-Id: I37170cafff7e8a4cc44f1622fe52a6cbff85f218
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
staging: zram: Rate limit memory allocation errors

If an error occurs allocating memory for zram we will not be able
to fullfill the request to store the page in zram. The swap subsystem
still continues to try to swap out pages to zram even when this error
occurs since there is currently no facility to stop the swap subsystem
from swapping out during such errors. This can cause the system to be
overflowed with logging errors.

Reduce the amount of logging to prevent the kernel log
from being filled with these error messages.

Change-Id: I54b920337749ece59d9ca78fa8b29345ec7b976b
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
staging: zsmalloc: Ensure handle is never 0 on success

zsmalloc encodes a handle using the pfn and an object
index. On hardware platforms with physical memory starting
at 0x0 the pfn can be 0. This causes the encoded handle to be
0 and is incorrectly interpreted as an allocation failure.

This issue affects all current and future SoCs with physical
memory starting at 0x0. All MSM8974 SoCs which includes
Google Nexus 5 devices are affected.

To prevent this false error we ensure that the encoded handle
will not be 0 when allocation succeeds.

Change-Id: I5ad31712be4dd5105ebee81fa95927039c0f6935
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>