On 09/27/2012 05:07 PM, Dan Magenheimer wrote:
> Of course, I'm of the opinion that neither zcache1 nor
> zcache2 would be likely to be promoted for at least another
> cycle or two, so if you go with zcache2+zsmalloc as the compromise
> and it still takes six months for promotion, I hope you don't
> blame that on the "rewrite". ;-)
>
> Anyway, looking forward (hopefully) to working with you on
> a good compromise. It would be nice to get back to coding
> and working together on a single path forward for zcache
> as there is a lot of work to do!
We want to see zcache moving forward so that it can get out of staging
and into the hands of end users. From the direction the discussion
has taken, replacing zcache with the new code appears to be the right
compromise for the situation. Moving to the new zcache code resets
the clock so I would like to know that we're all on the same track...
1- Promotion must be the top priority, focus needs to be on making the
code production ready rather than adding more features.
2- The code is in the community and development must be done in
public, no further large private rewrites.
3- Benchmarks need to be agreed on, Mel has suggested some of the
MMTests. We need a way to talk about performance so we can make
comparisions, avoid regressions, and talk about promotion criteria.
They should be something any developer can run.
4- Let's investigate breaking ramster out of zcache so that zcache
remains a separately testable building block; Konrad was looking at
this I believe. RAMSTer adds another functional mode for zcache and
adds to the difficulty of validating patches. Not every developer
has a cluster of machines to validate RAMSter.
Seth
> From: Seth Jennings [mailto:[email protected]]
> Subject: Re: [RFC] mm: add support for zsmalloc and zcache
>
> On 09/27/2012 05:07 PM, Dan Magenheimer wrote:
> > Of course, I'm of the opinion that neither zcache1 nor
> > zcache2 would be likely to be promoted for at least another
> > cycle or two, so if you go with zcache2+zsmalloc as the compromise
> > and it still takes six months for promotion, I hope you don't
> > blame that on the "rewrite". ;-)
> >
> > Anyway, looking forward (hopefully) to working with you on
> > a good compromise. It would be nice to get back to coding
> > and working together on a single path forward for zcache
> > as there is a lot of work to do!
>
> We want to see zcache moving forward so that it can get out of staging
> and into the hands of end users. From the direction the discussion
> has taken, replacing zcache with the new code appears to be the right
> compromise for the situation. Moving to the new zcache code resets
> the clock so I would like to know that we're all on the same track...
>
> 1- Promotion must be the top priority, focus needs to be on making the
> code production ready rather than adding more features.
Agreed.
> 2- The code is in the community and development must be done in
> public, no further large private rewrites.
Agreed.
> 3- Benchmarks need to be agreed on, Mel has suggested some of the
> MMTests. We need a way to talk about performance so we can make
> comparisions, avoid regressions, and talk about promotion criteria.
> They should be something any developer can run.
Agreed.
> 4- Let's investigate breaking ramster out of zcache so that zcache
> remains a separately testable building block; Konrad was looking at
> this I believe. RAMSTer adds another functional mode for zcache and
> adds to the difficulty of validating patches. Not every developer
> has a cluster of machines to validate RAMSter.
In zcache2 (which is now in Linus' 3.7-rc0 tree in the ramster directory),
ramster is already broken out. It can be disabled either at compile-time
(simply by not specifying CONFIG_RAMSTER) or at run-time (by using
"zcache" as the kernel boot parameter instead of "ramster").
So... also agreed. RAMster will not be allowed to get in the
way of promotion or performance as long as any reasonable attempt
is made to avoid breaking the existing hooks to RAMster.
(This only because I expect future functionality to also
use these hooks so would like to avoid breaking them, if possible.)
Does this last clarification work for you, Seth?
If so, <shake hands> and move forward? What do you see as next steps?
Dan
On 10/02/2012 01:17 PM, Dan Magenheimer wrote:
> If so, <shake hands> and move forward? What do you see as next steps?
I'll need to get up to speed on the new codebase before I can answer
this. I should be able to answer by early next week.
Seth
On 10/02/2012 01:17 PM, Dan Magenheimer wrote:
> If so, <shake hands> and move forward? What do you see as next steps?
I've been reviewing the changes between zcache and zcache2 and getting
a feel for the scope and direction of those changes.
- Getting the community engaged to review zcache1 at ~2300SLOC was
difficult.
- Adding RAMSter has meant adding RAMSter-specific code broadly across
zcache and increases the size of code to review to ~7600SLOC.
- The changes have blurred zcache's internal layering and increased
complexity beyond what a simple SLOC metric can reflect.
- Getting the community engaged in reviewing zcache2 will be difficult
and will require an exceptional amount of effort for maintainer and
reviewer.
It is difficult for me to know when it could be ready for mainline and
production use. While zcache2 isn't getting broad code reviews yet,
how do suggest managing that complexity to make the code maintainable
and get it reviewed?
Seth
On Fri, Oct 26, 2012 at 04:45:14PM -0500, Seth Jennings wrote:
> On 10/02/2012 01:17 PM, Dan Magenheimer wrote:
> > If so, <shake hands> and move forward? What do you see as next steps?
>
> I've been reviewing the changes between zcache and zcache2 and getting
> a feel for the scope and direction of those changes.
>
> - Getting the community engaged to review zcache1 at ~2300SLOC was
> difficult.
> - Adding RAMSter has meant adding RAMSter-specific code broadly across
> zcache and increases the size of code to review to ~7600SLOC.
One can ignore the drivers/staging/ramster/ramster* directory.
> - The changes have blurred zcache's internal layering and increased
> complexity beyond what a simple SLOC metric can reflect.
Not sure I see a problem.
> - Getting the community engaged in reviewing zcache2 will be difficult
> and will require an exceptional amount of effort for maintainer and
> reviewer.
Exceptional? I think if we start trimming the code down and moving it
around - and moving the 'ramster' specific calls to header files to
not be compiled - that should make it easier to read.
I mean the goal of any review is to address all of the concern you saw
when you were looking over the code. You probably have a page of
questions you asked yourself - and in all likehood the other reviewers
would ask the same questions. So if you address them - either by
giving comments or making the code easier to read - that would do it.
>
> It is difficult for me to know when it could be ready for mainline and
> production use. While zcache2 isn't getting broad code reviews yet,
> how do suggest managing that complexity to make the code maintainable
> and get it reviewed?
There are Mel's feedback that is also applicable to zcache2.
Thanks for looking at the code!
>
> Seth
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to [email protected]. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
>