Messages in this thread | | | Date | Thu, 22 Nov 2018 15:59:26 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH 4/6] zram: support idle page writeback |
| |
On (11/22/18 15:31), Minchan Kim wrote: > > > > I got what you mean now. Let's call it as "incompressible page wrieback" > > to prevent confusing. > > > > "incompressible page writeback" would be orthgonal feature. The goal is > > "let's save memory at the cost of *latency*". If the page is swapped-in > > soon, it's unfortunate. However, the design expects once it's swapped out, > > it means it's non-workingset so soonish swappined-in would be rather not > > many, theoritically compared to other workingset. > > If's it's too frequent, it means system were heavily overcommitted. > > Havid said, I agree it's not a good idea to enable incompressible page > writeback with idle page writeback. If you don't oppose, I want to add > new knob to "enable incompressible page writeback" so by default, > although we enable CONFIG_ZRAM_WRITEBACK, incompressible page writeback > is off until we enable the knob. > It would make some regressison if someone have used the feature but > I guess we are not too late. > > What do you think?
Yes, totally works for me!
"IDLE writeback" is superior to "incompressible writeback".
"incompressible writeback" is completely unpredictable and uncontrollable; it depens on data patterns and compression algorithms. While "IDLE writeback" is predictable.
I even suspect, that, *ideally*, we can remove "incompressible writeback". "IDLE pages" is a super set which also includes "incompressible" pages. So, technically, we still can do "incompressible writeback" from "IDLE writeback" path; but a much more reasonable one, based on a page idling period.
I understand that you want to keep "direct incompressible writeback" around. ZRAM is especially popular on devices which do suffer from flash wearout, so I can see "incompressible writeback" path becoming a dead code, long term.
-ss
| |