> From: Mel Gorman [mailto:mgorman@xxxxxxx] > Subject: Re: [RFC] mm: add support for zsmalloc and zcache > > On Fri, Sep 21, 2012 at 01:35:15PM -0700, Dan Magenheimer wrote: > > > From: Seth Jennings [mailto:sjenning@xxxxxxxxxxxxxxxxxx] > > > Subject: Re: [RFC] mm: add support for zsmalloc and zcache > > The two proposals: > > A) Recreate all the work done for zcache2 as a proper sequence of > > independent patches and apply them to zcache1. (Seth/Konrad) > > B) Add zsmalloc back in to zcache2 as an alternative allocator > > for frontswap pages. (Dan) > > Throwing it out there but .... > > C) Merge both, but freeze zcache1 except for critical fixes. Only allow > future work on zcache2. Document limitations of zcache1 and > workarounds until zcache2 is fully production ready. Hi Mel (with request for Seth below) -- (C) may be the politically-expedient solution but, personally, I think it is a bit insane and I suspect that any mm developer who were to deeply review both codebases side-by-side would come to the same conclusion. The cost in developer/maintainer time, and the confusion presented to the user/distro base if both are promoted/merged would be way too high, and IMHO completely unwarranted. Let me try to explain... I use the terms "zcache1" and "zcache2" only to clarify which codebase, not because they are dramatically different. I estimate that 85%-90% of the code in zcache1 and zcache2 is identical, not counting the allocator or comments/whitespace/janitorial! Zcache2 _is_ zcache1 with some good stuff added and with zsmalloc dropped. I think after careful study, there would be wide agreement among mm developers that the stuff added is all moving in the direction of making zcache "production-ready". IMHO, zcache1 has _never_ been production-ready, and zcache2 is merely a big step in the right direction. (Quick logistical aside: zcache2 is in staging-next and linux-next, currently housed under the drivers/staging/ramster directory... with !CONFIG_RAMSTER, ramster _is_ zcache2.) Seth (and IBM) seems to have a bee in his bonnet that the existing zcache1 code _must_ be promoted _soon_ with as little change as possible. Other than the fact that he didn't like my patching approach [1], the only technical objection Seth has raised to zcache2 is that he thinks zsmalloc is the best choice of allocator [2] for his limited benchmarking [3]. I've offered to put zsmalloc back in to zcache2 as an optional (even default) allocator, but that doesn't seem to be good enough for Seth. Any other technical objections to zcache2, or explanation for his urgent desire to promote zcache1, Seth (and IBM) is keeping close to his vest, which I find to be a bit disingenuous. So, I'd like to challenge Seth with a simple question: If zcache2 offers zsmalloc as an alternative (even default) allocator, what remaining _technical_ objections do you (Seth) have to merging zcache2 _instead_ of zcache1? If Mel agrees that your objections are worth the costs of bifurcating zcache and will still endorse merging both into core mm, I agree to move forward with Mel's alternative (C) (and will then repost https://lkml.org/lkml/2012/7/31/573). Personally, I would _really_ like to get back to writing code to make zcacheN more suitable for production so would really like to see this resolved! Dan [1] Monolithic, because GregKH seemed to be unwilling to take further patches to zcache before it was promoted, and because I thought a number of things had to be fixed before I would feel comfortable presenting zcache to be reviewed by mm developers [2] Note, zsmalloc is used in zcache1 only for frontswap pages... zbud is used in both zcache1 and zcache2 for cleancache pages. [3] I've never seen any benchmark results posted for zcache other than some variation of kernbench. IMHO that's an issue all in itself. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href