Re: [PATCH] zram: remove special handle of uncompressed page

[Nitin Gupta]

On 06/07/2012 11:39 PM, Minchan Kim wrote:

> xvmalloc can't handle PAGE_SIZE page so that zram have to
> handle it specially but zsmalloc can do it so let's remove
> unnecessary special handling code.
> 
> Quote from Nitin
> "I think page vs handle distinction was added since xvmalloc could not
> handle full page allocation. Now that zsmalloc allows full page
> allocation, we can just use it for both cases. This would also allow
> removing the ZRAM_UNCOMPRESSED flag. The only downside will be slightly
> slower code path for full page allocation but this event is anyways
> supposed to be rare, so should be fine."
> 
> 1. This patch reduces code very much.
> 
>  drivers/staging/zram/zram_drv.c   |  104 +++++--------------------------------
>  drivers/staging/zram/zram_drv.h   |   17 +-----
>  drivers/staging/zram/zram_sysfs.c |    6 +--
>  3 files changed, 15 insertions(+), 112 deletions(-)
> 
> 2. change pages_expand with bad_compress so it can count
>    bad compression(above 75%) ratio.
> 
> 3. remove zobj_header which is for back-reference for defragmentation
>    because firstly, it's not used at the moment and zsmalloc can't handle
>    bigger size than PAGE_SIZE so zram can't do it any more without redesign.
> 
> Cc: Nitin Gupta <ngupta@xxxxxxxxxx>
> Cc: Seth Jennings <sjenning@xxxxxxxxxxxxxxxxxx>
> Signed-off-by: Minchan Kim <minchan@xxxxxxxxxx>
> ---
>  drivers/staging/zram/zram_drv.c   |  104 +++++--------------------------------
>  drivers/staging/zram/zram_drv.h   |   17 +-----
>  drivers/staging/zram/zram_sysfs.c |    6 +--
>  3 files changed, 15 insertions(+), 112 deletions(-)
> 


I tried hard to figure out if these three things could be separated out
as separate patches but looks like that would make individual patches
unnecessarily messy.

Perhaps we should also add a fastpath for PAGE_SIZE'd objects in
zsmalloc but that's probably something for future work.


Acked-by: Nitin Gupta <ngupta@xxxxxxxxxx>

Thanks,
Nitin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/