[PATCH] zsmalloc/zcache: TODO list.

[Konrad Rzeszutek Wilk]

Adding in comments by Dan.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
---
 drivers/staging/zcache/TODO   |   21 +++++++++++++++++++++
 drivers/staging/zsmalloc/TODO |   17 +++++++++++++++++
 2 files changed, 38 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/zcache/TODO
 create mode 100644 drivers/staging/zsmalloc/TODO

diff --git a/drivers/staging/zcache/TODO b/drivers/staging/zcache/TODO
new file mode 100644
index 0000000..bf19a01
--- /dev/null
+++ b/drivers/staging/zcache/TODO
@@ -0,0 +1,21 @@
+
+A) Andrea Arcangeli pointed out and, after some deep thinking, I came
+   to agree that zcache _must_ have some "backdoor exit" for frontswap
+   pages [2], else bad things will eventually happen in many workloads.
+   This requires some kind of reaper of frontswap'ed zpages[1] which "evicts"
+   the data to the actual swap disk.  This reaper must ensure it can reclaim
+   _full_ pageframes (not just zpages) or it has little value.  Further the
+   reaper should determine which pageframes to reap based on an LRU-ish
+   (not random) approach.
+
+B) Zcache uses zbud(v1) for cleancache pages and includes a shrinker which
+   reclaims pairs of zpages to release whole pageframes, but there is
+   no attempt to shrink/reclaim cleanache pageframes in LRU order.
+   It would also be nice if single-cleancache-pageframe reclaim could
+   be implemented.
+
+C) Offer a mechanism to select whether zbud or zsmalloc should be used.
+   This should be for either cleancache or frontswap pages. Meaning there
+   are four choices: cleancache and frontswap using zbud; cleancache and
+   frontswap using zsmalloc; cleancache using zsmalloc, frontswap using zbud;
+   cleacache using zbud, and frontswap using zsmalloc.
diff --git a/drivers/staging/zsmalloc/TODO b/drivers/staging/zsmalloc/TODO
new file mode 100644
index 0000000..b1debad
--- /dev/null
+++ b/drivers/staging/zsmalloc/TODO
@@ -0,0 +1,17 @@
+
+A) Zsmalloc has potentially far superior density vs zbud because zsmalloc can
+   pack more zpages into each pageframe and allows for zpages that cross pageframe
+   boundaries.  But, (i) this is very data dependent... the average compression
+   for LZO is about 2x.  The frontswap'ed pages in the kernel compile benchmark
+   compress to about 4x, which is impressive but probably not representative of
+   a wide range of zpages and workloads.  And (ii) there are many historical
+   discussions going back to Knuth and mainframes about tight packing of data...
+   high density has some advantages but also brings many disadvantages related to
+   fragmentation and compaction.  Zbud is much less aggressive (max two zpages
+   per pageframe) but has a similar density on average data, without the
+   disadvantages of high density.
+
+   So zsmalloc may blow zbud away on a kernel compile benchmark but, if both were
+   runners, zsmalloc is a sprinter and zbud is a marathoner.  Perhaps the best
+   solution is to offer both?
+
-- 
1.7.7.6

--
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/