Re: [PATCH] mm/zswap: add writethrough option

[Bob Liu]

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/