From: Konrad Rzeszutek Wilk <email@example.com>
To: Dan Magenheimer <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org,
Subject: Re: [PATCH 0/3] staging: ramster: move to new zcache2 code base
Date: Thu, 30 Aug 2012 20:00:20 -0400 [thread overview]
Message-ID: <20120831000020.GA14628@localhost.localdomain> (raw)
On Thu, Aug 30, 2012 at 03:46:01PM -0700, Dan Magenheimer wrote:
> Hi Greg --
> gregkh> If you feel that the existing code needs to be dropped
> gregkh> and replaced with a totally new version, that's fine with
> gregkh> me. It's forward progress, which is all that I ask for.
> in reference to zcache, assuming applies to ramster as well)
> Please apply for staging-next for the 3.7 window to move ramster forward.
> Since AFAICT there have been no patches or contributions from others to
> drivers/staging/ramster since it was merged, this totally new version
> of ramster should not run afoul and the patches should apply to
> 3.5 or 3.6-rcN.
> When ramster was merged into staging at 3.4, it used a "temporarily" forked
> version of zcache. Code was proposed to merge zcache and ramster into
> a new common redesigned codebase which both resolves various serious design
> flaws and eliminates all code duplication between zcache and ramster, with
> the result to replace "zcache". Sadly, that proposal was blocked, so the
> zcache (and tmem) code in drivers/staging/zcache and the zcache (and tmem)
> code in drivers/staging/ramster continue to be different.
Right. They will diverge for now.
> This patchset moves ramster to the new redesigned codebase and calls that
> new codebase "zcache2". Most, if not all, of the redesign will eventually
> need to be merged with "zcache1" before zcache functionality should be
> promoted out of staging.
Or as part of ramster unstaging 'zcache1' can be made more in a
library so that ramster can use it. Naturally this also requires some
modifications in zcache1 to have the infrastructure functionality for
ramster. But that is something we can worry about later.
> An overview of the zcache2 rewrite is provided in a git commit comment
> later in this series.
> A significant item of debate in the new codebase is the removal of zsmalloc.
Just clarifying since what you mean is that in your ramster's version
of zcache (so zcache2), as you are not using it.
> This removal may be temporary if zsmalloc is enhanced with necessary
> features to meet the needs of the new zcache codebase. Justification
> for the change can be found at http://lkml.org/lkml/2012/8/15/292
> Such zsmalloc enhancments will almost certainly necessitate a major
> rework, not a small patch.
Or have the zcache be able to select whether its going to use zbud
or xsmalloc for any type of pages (so you could use xsmalloc for
both cleancache and frontswap pages, or be more selective like
> While this zcache2 codebase is far from perfect (and thus remains in staging),
> the foundation is now cleaner, more stable, more maintainable, and much
> better commented.
> Signed-off-by: Dan Magenheimer <email@example.com>
> drivers/staging/Kconfig | 4 +-
> drivers/staging/Makefile | 2 +-
> drivers/staging/ramster/Kconfig | 25 +-
> drivers/staging/ramster/Makefile | 7 +-
> drivers/staging/ramster/TODO | 13 -
> drivers/staging/ramster/cluster/Makefile | 3 -
> drivers/staging/ramster/cluster/heartbeat.c | 464 ---
> drivers/staging/ramster/cluster/heartbeat.h | 87 -
> drivers/staging/ramster/cluster/masklog.c | 155 -
> drivers/staging/ramster/cluster/masklog.h | 220 --
> drivers/staging/ramster/cluster/nodemanager.c | 992 ------
> drivers/staging/ramster/cluster/nodemanager.h | 88 -
> .../staging/ramster/cluster/ramster_nodemanager.h | 39 -
> drivers/staging/ramster/cluster/tcp.c | 2256 -------------
> drivers/staging/ramster/cluster/tcp.h | 159 -
> drivers/staging/ramster/cluster/tcp_internal.h | 248 --
> drivers/staging/ramster/r2net.c | 401 ---
> drivers/staging/ramster/ramster.h | 113 +-
> drivers/staging/ramster/ramster/heartbeat.c | 462 +++
> drivers/staging/ramster/ramster/heartbeat.h | 87 +
> drivers/staging/ramster/ramster/masklog.c | 155 +
> drivers/staging/ramster/ramster/masklog.h | 220 ++
> drivers/staging/ramster/ramster/nodemanager.c | 995 ++++++
> drivers/staging/ramster/ramster/nodemanager.h | 88 +
> drivers/staging/ramster/ramster/r2net.c | 414 +++
> drivers/staging/ramster/ramster/ramster.c | 985 ++++++
> drivers/staging/ramster/ramster/ramster.h | 161 +
> .../staging/ramster/ramster/ramster_nodemanager.h | 39 +
> drivers/staging/ramster/ramster/tcp.c | 2253 +++++++++++++
> drivers/staging/ramster/ramster/tcp.h | 159 +
> drivers/staging/ramster/ramster/tcp_internal.h | 248 ++
> drivers/staging/ramster/tmem.c | 313 +-
> drivers/staging/ramster/tmem.h | 109 +-
> drivers/staging/ramster/xvmalloc.c | 509 ---
> drivers/staging/ramster/xvmalloc.h | 30 -
> drivers/staging/ramster/xvmalloc_int.h | 95 -
> drivers/staging/ramster/zbud.c | 1060 ++++++
> drivers/staging/ramster/zbud.h | 33 +
> drivers/staging/ramster/zcache-main.c | 3532 ++++++--------------
> drivers/staging/ramster/zcache.h | 55 +-
> 40 files changed, 8711 insertions(+), 8567 deletions(-)
next prev parent reply other threads:[~2012-08-31 0:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-30 22:46 [PATCH 0/3] staging: ramster: move to new zcache2 code base Dan Magenheimer
2012-08-30 22:46 ` [PATCH 1/3] staging: ramster: remove old driver to prep for new base Dan Magenheimer
2012-09-05 19:03 ` Greg KH
2012-08-30 22:46 ` [PATCH 2/3] staging: ramster: move to new zcache2 codebase Dan Magenheimer
2012-08-30 22:46 ` [PATCH 3/3] staging: ramster: place ramster codebase on top of " Dan Magenheimer
2012-08-31 0:00 ` Konrad Rzeszutek Wilk [this message]
2012-09-04 21:38 ` [PATCH 0/3] staging: ramster: move to new zcache2 code base Greg KH
2012-09-05 11:55 ` Konrad Rzeszutek Wilk
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).