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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>