Re: [PATCH] [staging][zram] Fix handling of incompressible pages

[Minchan Kim <minchan@kernel.org>]

On Tue, Oct 09, 2012 at 10:35:24AM -0700, Nitin Gupta wrote:
> Hi Minchan,
> 
> On 10/09/2012 06:31 AM, Minchan Kim wrote:
> >
> >On Mon, Oct 08, 2012 at 06:32:44PM -0700, Nitin Gupta wrote:
> >>Change 130f315a introduced a bug in the handling of incompressible
> >>pages which resulted in memory allocation failure for such pages.
> >>The fix is to store the page as-is i.e. without compression if the
> >>compressed size exceeds a threshold (max_zpage_size) and request
> >>exactly PAGE_SIZE sized buffer from zsmalloc.
> >
> >It seems you found a bug and already fixed it with below helpers.
> >But unfortunately, description isn't enough to understand the problem for me.
> >Could you explain in detail?
> >You said it results in memory allocation failure. What is failure?
> >You mean this code by needing a few pages for zspage to meet class size?
> >
> >         handle = zs_malloc(zram->mem_pool, clen);
> >         if (!handle) {
> >                 pr_info("Error allocating memory for compressed "
> >                         "page: %u, size=%zu\n", index, clen);
> >                 ret = -ENOMEM;
> >                 goto out;
> >         }
> >
> >So instead of allocating more pages for incompressible page to make zspage,
> >just allocate a page for PAGE_SIZE class without compression?
> >
> 
> When a page expands on compression, say from 4K to 4K+30, we were
> trying to do zsmalloc(pool, 4K+30). However, the maximum size which
> zsmalloc can allocate is PAGE_SIZE (for obvious reasons), so such
> allocation requests always return failure (0).

Right.
I think it would be better to add this explanation in description.

> 
> For a page that has compressed size larger than the original size
> (this may happen with already compressed or random data), there is
> no point storing the compressed version as that would take more
> space and would also require time for decompression when needed
> again. So, the fix is to store any page, whose compressed size
> exceeds a threshold (max_zpage_size), as-it-is i.e. without
> compression.  Memory required for storing this uncompressed page can

Yes. It's already definition of max_zpage_size.

> then be requested from zsmalloc which supports PAGE_SIZE sized
> allocations.

> 
> Lastly, the fix checks that we do not attempt to "decompress" the
> page which we stored in the uncompressed form -- we just memcpy()
> out such pages.
> 
> Thanks,
> Nitin
> 
> 
> >>
> >>Signed-off-by: Nitin Gupta <ngupta@vflare.org>
> >>Reported-by: viechweg@gmail.com
> >>Reported-by: paerley@gmail.com
> >>Reported-by: wu.tommy@gmail.com
> >>Tested-by: wu.tommy@gmail.com
> >>Tested-by: michael@zugelder.org
Anyway, 
Acked-by: Minchan Kim <minchan@kernel.org>

Thanks, Nitin!
-- 
Kind regards,
Minchan Kim