lkml.org 
[lkml]   [2014]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v2] mm/zswap: add writethrough option
On Mon, Feb 3, 2014 at 6:08 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Mon, 27 Jan 2014 09:01:19 -0500 Dan Streetman <ddstreet@ieee.org> wrote:
>
>> Currently, zswap is writeback cache; stored pages are not sent
>> to swap disk, and when zswap wants to evict old pages it must
>> first write them back to swap cache/disk manually. This avoids
>> swap out disk I/O up front, but only moves that disk I/O to
>> the writeback case (for pages that are evicted), and adds the
>> overhead of having to uncompress the evicted pages and the
>> need for an additional free page (to store the uncompressed page).
>>
>> This optionally changes zswap to writethrough cache by enabling
>> frontswap_writethrough() before registering, so that any
>> successful page store will also be written to swap disk. The
>> default remains writeback. To enable writethrough, the param
>> zswap.writethrough=1 must be used at boot.
>>
>> Whether writeback or writethrough will provide better performance
>> depends on many factors including disk I/O speed/throughput,
>> CPU speed(s), system load, etc. In most cases it is likely
>> that writeback has better performance than writethrough before
>> zswap is full, but after zswap fills up writethrough has
>> better performance than writeback.
>>
>> The reason to add this option now is, first to allow any zswap
>> user to be able to test using writethrough to determine if they
>> get better performance than using writeback, and second to allow
>> future updates to zswap, such as the possibility of dynamically
>> switching between writeback and writethrough.
>>
>> ...
>>
>> Based on specjbb testing on my laptop, the results for both writeback
>> and writethrough are better than not using zswap at all, but writeback
>> does seem to be better than writethrough while zswap isn't full. Once
>> it fills up, performance for writethrough is essentially close to not
>> using zswap, while writeback seems to be worse than not using zswap.
>> However, I think more testing on a wider span of systems and conditions
>> is needed. Additionally, I'm not sure that specjbb is measuring true
>> performance under fully loaded cpu conditions, so additional cpu load
>> might need to be added or specjbb parameters modified (I took the
>> values from the 4 "warehouses" test run).
>>
>> In any case though, I think having writethrough as an option is still
>> useful. More changes could be made, such as changing from writeback
>> to writethrough based on the zswap % full. And the patch doesn't
>> change default behavior - writethrough must be specifically enabled.
>>
>> The %-ized numbers I got from specjbb on average, using the default
>> 20% max_pool_percent and varying the amount of heap used as shown:
>>
>> ram | no zswap | writeback | writethrough
>> 75 93.08 100 96.90
>> 87 96.58 95.58 96.72
>> 100 92.29 89.73 86.75
>> 112 63.80 38.66 19.66
>> 125 4.79 29.90 15.75
>> 137 4.99 4.50 4.75
>> 150 4.28 4.62 5.01
>> 162 5.20 2.94 4.66
>> 175 5.71 2.11 4.84
>
> Changelog is very useful, thanks for taking the time.
>
> It does sound like the feature is of marginal benefit. Is "zswap
> filled up" an interesting or useful case to optimize?
>
> otoh the addition is pretty simple and we can later withdraw the whole
> thing without breaking anyone's systems.

ping...

you still thinking about this or is it a reject for now?

>
> What do people think?
>
>


\
 
 \ /
  Last update: 2014-02-10 21:01    [W:2.232 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site