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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>