On 01/23/2014 08:18 AM, Minchan Kim wrote: > Hello all, > > On Wed, Jan 22, 2014 at 12:33:58PM -0800, Andrew Morton wrote: >> On Wed, 22 Jan 2014 09:19:58 -0500 Dan Streetman <ddstreet@xxxxxxxx> wrote: >> >>>>>>> Acutally, I really don't know how much benefit we have that in-memory >>>>>>> swap overcomming to the real storage but if you want, zRAM with dm-cache >>>>>>> is another option rather than invent new wheel by "just having is better". >>>>>> >>>>>> I'm not sure if this patch is related to the zswap vs. zram discussions. This >>>>>> only adds the option of using writethrough to zswap. It's a first >>>>>> step to possibly >>>>>> making zswap work more efficiently using writeback and/or writethrough >>>>>> depending on >>>>>> the system and conditions. >>>>> >>>>> The patch size is small. Okay I don't want to be a party-pooper >>>>> but at least, I should say my thought for Andrew to help judging. >>>> >>>> Sure, I'm glad to have your suggestions. >>> >>> To give this a bump - Andrew do you have any concerns about this >>> patch? Or can you pick this up? >> >> I don't pay much attention to new features during the merge window, >> preferring to shove them into a folder to look at later. Often they >> have bitrotted by the time -rc1 comes around. >> >> I'm not sure that this review discussion has played out yet - is >> Minchan happy? > > From the beginning, zswap is for reducing swap I/O but if workingset > overflows, it should write back rather than OOM with expecting a small > number of writeback would make the system happy because the high memory > pressure is temporal so soon most of workload would be hit in zswap > without further writeback. > > If memory pressure continues and writeback steadily, it means zswap's > benefit would be mitigated, even worse by addding comp/decomp overhead. > In that case, it would be better to disable zswap, even. > > Dan said writethrough supporting is first step to make zswap smart > but anybody didn't say further words to step into the smart and > what's the *real* workload want it and what's the *real* number from > that because dm-cache/zram might be a good fit. > (I don't intend to argue zram VS zswap. If the concern is solved by > existing solution, why should we invent new function and > have maintenace cost?) so it's very hard for me to judge that we should > accept and maintain it. > Speak of dm-cache, there are also bcache, flashcache and bcache. > We need blueprint for the future and make an agreement on the > direction before merging this patch. > > But code size is not much and Seth already gave an his Ack so I don't > want to hurt Dan any more(Sorry for Dan) and wasting my time so pass > the decision to others(ex, Seth and Bob). Since zswap is a cache layer and write-back and write-through are two common options for any cache. I'm fine with adding this write-through option. Thanks, -Bob -- 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>