Re: [PATCH v2] mm/zswap: add writethrough option
On Mon, Feb 10, 2014 at 6:06 PM, Andrew Morton wrote: > On Mon, 10 Feb 2014 14:05:14 -0500 Dan Streetman wrote: > >> > >> > 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? > > I'm not seeing a compelling case for merging it and Minchan sounded > rather unconvinced. Perhaps we should park it until/unless a more > solid need is found? Sounds good. I'll bring it back up if I find some solid need for it. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm/zswap: add writethrough option
On Mon, Feb 10, 2014 at 6:06 PM, Andrew Morton a...@linux-foundation.org wrote: On Mon, 10 Feb 2014 14:05:14 -0500 Dan Streetman ddstr...@ieee.org wrote: 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? I'm not seeing a compelling case for merging it and Minchan sounded rather unconvinced. Perhaps we should park it until/unless a more solid need is found? Sounds good. I'll bring it back up if I find some solid need for it. Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm/zswap: add writethrough option
On Mon, 10 Feb 2014 14:05:14 -0500 Dan Streetman wrote: > > > > 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? I'm not seeing a compelling case for merging it and Minchan sounded rather unconvinced. Perhaps we should park it until/unless a more solid need is found? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm/zswap: add writethrough option
On Mon, Feb 3, 2014 at 6:08 PM, Andrew Morton wrote: > On Mon, 27 Jan 2014 09:01:19 -0500 Dan Streetman 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 >> 10092.29 89.73 86.75 >> 11263.80 38.66 19.66 >> 1254.79 29.90 15.75 >> 1374.99 4.504.75 >> 1504.28 4.625.01 >> 1625.20 2.944.66 >> 1755.71 2.114.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? > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm/zswap: add writethrough option
On Mon, Feb 3, 2014 at 6:08 PM, Andrew Morton a...@linux-foundation.org wrote: On Mon, 27 Jan 2014 09:01:19 -0500 Dan Streetman ddstr...@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 10092.29 89.73 86.75 11263.80 38.66 19.66 1254.79 29.90 15.75 1374.99 4.504.75 1504.28 4.625.01 1625.20 2.944.66 1755.71 2.114.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? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm/zswap: add writethrough option
On Mon, 10 Feb 2014 14:05:14 -0500 Dan Streetman ddstr...@ieee.org wrote: 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? I'm not seeing a compelling case for merging it and Minchan sounded rather unconvinced. Perhaps we should park it until/unless a more solid need is found? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm/zswap: add writethrough option
Hello Andrew, On Mon, Feb 03, 2014 at 03:08:35PM -0800, Andrew Morton wrote: > On Mon, 27 Jan 2014 09:01:19 -0500 Dan Streetman 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 > > 10092.29 89.73 86.75 > > 11263.80 38.66 19.66 > > 1254.79 29.90 15.75 > > 1374.99 4.504.75 > > 1504.28 4.625.01 > > 1625.20 2.944.66 > > 1755.71 2.114.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. > > What do people think? IMHO, Using overcommiting memory and swap, it's really thing we shold optimize once we decided to use writeback of zswap. But I don't think writethrough isn't ideal solution for that case where zswap is full. Sometime, just dynamic disabling of zswap might be better due to reducing unnecessary comp/decomp overhead. Dan said that it's good to have because someuser might find right example we didn't find in future. Although I'm not a huge fan of such justification for merging the patch(I tempted my patches several time with such claim), I don't object it (Actually, I have an idea to make zswap's writethough useful but it isn't related to this topic) any more if we could withdraw easily if it turns out a obstacle for future enhace. Thanks. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm/zswap: add writethrough option
On Mon, 27 Jan 2014 09:01:19 -0500 Dan Streetman 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 > 10092.29 89.73 86.75 > 11263.80 38.66 19.66 > 1254.79 29.90 15.75 > 1374.99 4.504.75 > 1504.28 4.625.01 > 1625.20 2.944.66 > 1755.71 2.114.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. What do people think? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm/zswap: add writethrough option
On Mon, 27 Jan 2014 09:01:19 -0500 Dan Streetman ddstr...@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 10092.29 89.73 86.75 11263.80 38.66 19.66 1254.79 29.90 15.75 1374.99 4.504.75 1504.28 4.625.01 1625.20 2.944.66 1755.71 2.114.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. What do people think? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm/zswap: add writethrough option
Hello Andrew, On Mon, Feb 03, 2014 at 03:08:35PM -0800, Andrew Morton wrote: On Mon, 27 Jan 2014 09:01:19 -0500 Dan Streetman ddstr...@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 10092.29 89.73 86.75 11263.80 38.66 19.66 1254.79 29.90 15.75 1374.99 4.504.75 1504.28 4.625.01 1625.20 2.944.66 1755.71 2.114.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. What do people think? IMHO, Using overcommiting memory and swap, it's really thing we shold optimize once we decided to use writeback of zswap. But I don't think writethrough isn't ideal solution for that case where zswap is full. Sometime, just dynamic disabling of zswap might be better due to reducing unnecessary comp/decomp overhead. Dan said that it's good to have because someuser might find right example we didn't find in future. Although I'm not a huge fan of such justification for merging the patch(I tempted my patches several time with such claim), I don't object it (Actually, I have an idea to make zswap's writethough useful but it isn't related to this topic) any more if we could withdraw easily if it turns out a obstacle for future enhace. Thanks. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] mm/zswap: add writethrough option
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.
Signed-off-by: Dan Streetman
---
Changes in v2:
- update changelog with reasoning to include patch now,
in response to Minchan's concerns
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
10092.29 89.73 86.75
11263.80 38.66 19.66
1254.79 29.90 15.75
1374.99 4.504.75
1504.28 4.625.01
1625.20 2.944.66
1755.71 2.114.84
mm/zswap.c | 68 ++
1 file changed, 64 insertions(+), 4 deletions(-)
diff --git a/mm/zswap.c b/mm/zswap.c
index e55bab9..2f919db 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -61,6 +61,8 @@ static atomic_t zswap_stored_pages = ATOMIC_INIT(0);
static u64 zswap_pool_limit_hit;
/* Pages written back when pool limit was reached */
static u64 zswap_written_back_pages;
+/* Pages evicted when pool limit was reached */
+static u64 zswap_evicted_pages;
/* Store failed due to a reclaim failure after pool limit was reached */
static u64 zswap_reject_reclaim_fail;
/* Compressed page was too big for the allocator to (optimally) store */
@@ -89,6 +91,10 @@ static unsigned int zswap_max_pool_percent = 20;
module_param_named(max_pool_percent,
zswap_max_pool_percent, uint, 0644);
+/* Writeback/writethrough mode (fixed at boot for now) */
+static bool zswap_writethrough;
+module_param_named(writethrough, zswap_writethrough, bool, 0444);
+
/*
* compression functions
**/
@@ -629,6 +635,48 @@ end:
}
/*
+* evict code
+**/
+
+/*
+ * This evicts pages that have already been written through to swap.
+ */
+static int zswap_evict_entry(struct zbud_pool *pool, unsigned long handle)
+{
+ struct zswap_header *zhdr;
+ swp_entry_t swpentry;
+ struct zswap_tree *tree;
+ pgoff_t offset;
+ struct zswap_entry *entry;
+
+ /* extract swpentry from data */
+ zhdr = zbud_map(pool, handle);
+ swpentry = zhdr->swpentry; /* here */
+ zbud_unmap(pool, handle);
+ tree = zswap_trees[swp_type(swpentry)];
+ offset = swp_offset(swpentry);
+ BUG_ON(pool != tree->pool);
+
+ /* find and ref zswap entry */
+ spin_lock(>lock);
+ entry = zswap_rb_search(>rbroot, offset);
+ if (!entry) {
+ /* entry was invalidated */
+
[PATCH v2] mm/zswap: add writethrough option
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.
Signed-off-by: Dan Streetman ddstr...@ieee.org
---
Changes in v2:
- update changelog with reasoning to include patch now,
in response to Minchan's concerns
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
10092.29 89.73 86.75
11263.80 38.66 19.66
1254.79 29.90 15.75
1374.99 4.504.75
1504.28 4.625.01
1625.20 2.944.66
1755.71 2.114.84
mm/zswap.c | 68 ++
1 file changed, 64 insertions(+), 4 deletions(-)
diff --git a/mm/zswap.c b/mm/zswap.c
index e55bab9..2f919db 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -61,6 +61,8 @@ static atomic_t zswap_stored_pages = ATOMIC_INIT(0);
static u64 zswap_pool_limit_hit;
/* Pages written back when pool limit was reached */
static u64 zswap_written_back_pages;
+/* Pages evicted when pool limit was reached */
+static u64 zswap_evicted_pages;
/* Store failed due to a reclaim failure after pool limit was reached */
static u64 zswap_reject_reclaim_fail;
/* Compressed page was too big for the allocator to (optimally) store */
@@ -89,6 +91,10 @@ static unsigned int zswap_max_pool_percent = 20;
module_param_named(max_pool_percent,
zswap_max_pool_percent, uint, 0644);
+/* Writeback/writethrough mode (fixed at boot for now) */
+static bool zswap_writethrough;
+module_param_named(writethrough, zswap_writethrough, bool, 0444);
+
/*
* compression functions
**/
@@ -629,6 +635,48 @@ end:
}
/*
+* evict code
+**/
+
+/*
+ * This evicts pages that have already been written through to swap.
+ */
+static int zswap_evict_entry(struct zbud_pool *pool, unsigned long handle)
+{
+ struct zswap_header *zhdr;
+ swp_entry_t swpentry;
+ struct zswap_tree *tree;
+ pgoff_t offset;
+ struct zswap_entry *entry;
+
+ /* extract swpentry from data */
+ zhdr = zbud_map(pool, handle);
+ swpentry = zhdr-swpentry; /* here */
+ zbud_unmap(pool, handle);
+ tree = zswap_trees[swp_type(swpentry)];
+ offset = swp_offset(swpentry);
+ BUG_ON(pool != tree-pool);
+
+ /* find and ref zswap entry */
+ spin_lock(tree-lock);
+ entry = zswap_rb_search(tree-rbroot, offset);
+ if (!entry) {
+ /* entry was
