Re: [RFC][PATCH v2 2/3] zram: use zs_get_huge_class_size_watermark()

[Sergey Senozhatsky]

On (02/22/16 09:04), Minchan Kim wrote:
[..]
> max_zpage_size was there since zram's grandpa(ie, ramzswap).
> AFAIR, at that time, it works to forward incompressible
> (e.g, PAGE_SIZE/2) page to backing swap if it presents.
> If it doesn't have any backing swap and it's incompressbile
> (e.g, PAGE_SIZE*3/4), it stores it as uncompressed page
> to avoid *decompress* overhead later.

"PAGE_SIZE * 3 / 4" introduces a bigger memory overhead than
decompression of 3K bytes later.

> And Nitin want to make it as tunable parameter. I agree the
> approach because I don't want to make coupling between zram
> and allocator as far as possible.
> 
> If huge class is pain

they are.

> it's allocator problem, not zram stuff.

the allocator's problems start at the point where zram begins to have
opinion on what should be stored as ->huge object and what should not.
it's not up to zram to enforce this.


> I think we should try to remove such problem in zsmalloc layer,
> firstly.

zram asks to store a PAGE_SIZE sized object, what zsmalloc can
possible do about this?


> Having said that, I agree your claim that uncompressible pages
> are pain. I want to handle the problem as multiple-swap apparoach.

zram is not just for swapping. as simple as that.


and enforcing a multi-swap approach on folks who use zram for swap
doesn't look right to me.


> For that, we should introduce new knob in zram layer like Nitin
> did and make it configurable so we could solve the problem of
> single zram-swap system as well as multiple swap system.

a 'bad compression' watermark knob? isn't it an absolutely low level
thing no one ever should see?

	-ss