[V2: no code changes, patchset now generated via git format-patch -M]
In staging, rename ramster to zcache
The original zcache in staging was a "demo" version, and this new zcache
is a significant rewrite. While certain disagreements were being resolved,
both "old zcache" and "new zcache" needed to reside in the staging tree
simultaneously. In order to minimize code change and churn, the newer
version of zcache was temporarily merged into the "ramster" staging driver
which, prior to that, had at one time heavily leveraged the older version
of zcache. So, recently, "new zcache" resided in the ramster directory.
Got that? No? Sorry, temporary political compromises are rarely pretty.
The older version of zcache is no longer being maintained and has now
been removed from the staging tree. So now the newer version of zcache
can rightfully reclaim sole possession of the name "zcache".
FYI, this [PATCH 2/5] is simply a "git mv" generated by "git format-patch -M".
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Magenheimer says that it is now safe to delete zcache, so quick,
before he changes his mind, drop the thing on the floor and run
screaming away.
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tmem_obj_find and insertion tmem-obj have the some logic, we can integrate
the code
Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
"ret" needs to be signed for the error handling to work properly.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is version 3 of an update to zcache, incorporating feedback from the list.
This patch adds support to the in-kernel transcendent memory ("tmem") code
and the zcache driver for multiple clients, which will be needed for both
RAMster and KVM support. It also adds additional tmem callbacks to support
RAMster and corresponding no-op stubs in the zcache driver. In v2, I've
also taken the liberty of adding some additional sysfs variables to
both surface information and allow policy control. Those experimenting
with zcache should find them useful. V3 clarifies some code walking
and declaring arrays.
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
[v3: error27@gmail.com: fix array bounds/walking]
[v2: konrad.wilk@oracle.com: fix bools, add check for NULL, fix a comment]
[v2: sjenning@linux.vnet.ibm.com: add info/tunables for poor compression]
[v2: marcusklemm@googlemail.com: add tunable for max persistent pages]
Acked-by: Dan Carpenter <error27@gmail.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: linux-mm@kvack.org
Cc: kvm@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH V2 1/3] drivers/staging: zcache: in-kernel tmem code
Transcendent memory ("tmem") is a clean API/ABI that provides
for an efficient address translation and a set of highly
concurrent access methods to copy data between a page-oriented
data source (e.g. cleancache or frontswap) and a page-addressable
memory ("PAM") data store. Of critical importance, the PAM data
store is of unknown (and possibly varying) size so any individual
access may succeed or fail as defined by the API/ABI.
Tmem exports a basic set of access methods (e.g. put, get,
flush, flush object, new pool, and destroy pool) which are
normally called from a "host" (e.g. zcache).
To be functional, two sets of "ops" must be registered by the
host, one to provide "host services" (memory allocation) and
one to provide page-addressable memory ("PAM") hooks.
Tmem supports one or more "clients", each which can provide
a set of "pools" to partition pages. Each pool contains
a set of "objects"; each object holds pointers to some number
of PAM page descriptors ("pampd"), indexed by an "index" number.
This triple <pool id, object id, index> is sometimes referred
to as a "handle". Tmem's primary function is to essentially
provide address translation of handles into pampds and move
data appropriately.
As an example, for cleancache, a pool maps to a filesystem,
an object maps to a file, and the index is the page offset
into the file. And in this patch, zcache is the host and
each PAM descriptor points to a compressed page of data.
Tmem supports two kinds of pages: "ephemeral" and "persistent".
Ephemeral pages may be asynchronously reclaimed "bottoms up"
so the data structures and concurrency model must allow for
this. For example, each pampd must retain sufficient information
to invalidate tmem's handle-to-pampd translation.
its containing object so that, on reclaim, all tmem data
structures can be made consistent.
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Magenheimer