RE: [PATCH 0/4] promote zcache from staging
> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > Sent: Friday, August 17, 2012 5:33 PM > To: Dan Magenheimer > Cc: Greg Kroah-Hartman; Andrew Morton; Nitin Gupta; Minchan Kim; Konrad Wilk; > Robert Jennings; linux- > m...@kvack.org; linux-kernel@vger.kernel.org; de...@driverdev.osuosl.org; > Kurt Hackel > Subject: Re: [PATCH 0/4] promote zcache from staging > > > > > Sorry to beat a dead horse, but I meant to report this > > earlier in the week and got tied up by other things. > > > > I finally got my test scaffold set up earlier this week > > to try to reproduce my "bad" numbers with the RHEL6-ish > > config file. > > > > I found that with "make -j28" and "make -j32" I experienced > > __DATA CORRUPTION__. This was repeatable. > > I actually hit this for the first time a few hours ago when > I was running performance for your rewrite. I didn't know > what to make of it yet. The 24-thread kernel build failed > when both frontswap and cleancache were enabled. > > > The type of error led me to believe that the problem was > > due to concurrency of cleancache reclaim. I did not try > > with cleancache disabled to prove/support this theory > > but it is consistent with the fact that you (Seth) have not > > seen a similar problem and has disabled cleancache. > > > > While this problem is most likely in my code and I am > > suitably chagrined, it re-emphasizes the fact that > > the current zcache in staging is 20-month old "demo" > > code. The proposed new zcache codebase handles concurrency > > much more effectively. > > I imagine this can be solved without rewriting the entire > codebase. If your new code contains a fix for this, can we > just pull it as a single patch? Hi Seth -- I didn't even observe this before this week, let alone fix this as an individual bug. The redesign takes into account LRU ordering and zombie pageframes (which have valid pointers to the contained zbuds and possibly valid data, so can't be recycled yet), taking races and concurrency carefully into account. The demo codebase is pretty dumb about concurrency, really a hack that seemed to work. Given the above, I guess the hack only works _most_ of the time... when it doesn't data corruption can occur. It would be an interesting challenge, but likely very time-consuming, to fix this one bug while minimizing other changes so that the fix could be delivered as a self-contained incremental patch. I suspect if you try, you will learn why the rewrite was preferable and necessary. (Away from email for a few days very soon now.) Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] Sent: Friday, August 17, 2012 5:33 PM To: Dan Magenheimer Cc: Greg Kroah-Hartman; Andrew Morton; Nitin Gupta; Minchan Kim; Konrad Wilk; Robert Jennings; linux- m...@kvack.org; linux-kernel@vger.kernel.org; de...@driverdev.osuosl.org; Kurt Hackel Subject: Re: [PATCH 0/4] promote zcache from staging Sorry to beat a dead horse, but I meant to report this earlier in the week and got tied up by other things. I finally got my test scaffold set up earlier this week to try to reproduce my bad numbers with the RHEL6-ish config file. I found that with make -j28 and make -j32 I experienced __DATA CORRUPTION__. This was repeatable. I actually hit this for the first time a few hours ago when I was running performance for your rewrite. I didn't know what to make of it yet. The 24-thread kernel build failed when both frontswap and cleancache were enabled. The type of error led me to believe that the problem was due to concurrency of cleancache reclaim. I did not try with cleancache disabled to prove/support this theory but it is consistent with the fact that you (Seth) have not seen a similar problem and has disabled cleancache. While this problem is most likely in my code and I am suitably chagrined, it re-emphasizes the fact that the current zcache in staging is 20-month old demo code. The proposed new zcache codebase handles concurrency much more effectively. I imagine this can be solved without rewriting the entire codebase. If your new code contains a fix for this, can we just pull it as a single patch? Hi Seth -- I didn't even observe this before this week, let alone fix this as an individual bug. The redesign takes into account LRU ordering and zombie pageframes (which have valid pointers to the contained zbuds and possibly valid data, so can't be recycled yet), taking races and concurrency carefully into account. The demo codebase is pretty dumb about concurrency, really a hack that seemed to work. Given the above, I guess the hack only works _most_ of the time... when it doesn't data corruption can occur. It would be an interesting challenge, but likely very time-consuming, to fix this one bug while minimizing other changes so that the fix could be delivered as a self-contained incremental patch. I suspect if you try, you will learn why the rewrite was preferable and necessary. (Away from email for a few days very soon now.) Dan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On 08/17/2012 05:21 PM, Dan Magenheimer wrote: >> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] >> Subject: Re: [PATCH 0/4] promote zcache from staging >> >> On 08/09/2012 03:20 PM, Dan Magenheimer wrote >>> I also wonder if you have anything else unusual in your >>> test setup, such as a fast swap disk (mine is a partition >>> on the same rotating disk as source and target of the kernel build, >>> the default install for a RHEL6 system)? >> >> I'm using a normal SATA HDD with two partitions, one for >> swap and the other an ext3 filesystem with the kernel source. >> >>> Or have you disabled cleancache? >> >> Yes, I _did_ disable cleancache. I could see where having >> cleancache enabled could explain the difference in results. > > Sorry to beat a dead horse, but I meant to report this > earlier in the week and got tied up by other things. > > I finally got my test scaffold set up earlier this week > to try to reproduce my "bad" numbers with the RHEL6-ish > config file. > > I found that with "make -j28" and "make -j32" I experienced > __DATA CORRUPTION__. This was repeatable. I actually hit this for the first time a few hours ago when I was running performance for your rewrite. I didn't know what to make of it yet. The 24-thread kernel build failed when both frontswap and cleancache were enabled. > The type of error led me to believe that the problem was > due to concurrency of cleancache reclaim. I did not try > with cleancache disabled to prove/support this theory > but it is consistent with the fact that you (Seth) have not > seen a similar problem and has disabled cleancache. > > While this problem is most likely in my code and I am > suitably chagrined, it re-emphasizes the fact that > the current zcache in staging is 20-month old "demo" > code. The proposed new zcache codebase handles concurrency > much more effectively. I imagine this can be solved without rewriting the entire codebase. If your new code contains a fix for this, can we just pull it as a single patch? Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > Subject: Re: [PATCH 0/4] promote zcache from staging > > On 08/09/2012 03:20 PM, Dan Magenheimer wrote > > I also wonder if you have anything else unusual in your > > test setup, such as a fast swap disk (mine is a partition > > on the same rotating disk as source and target of the kernel build, > > the default install for a RHEL6 system)? > > I'm using a normal SATA HDD with two partitions, one for > swap and the other an ext3 filesystem with the kernel source. > > > Or have you disabled cleancache? > > Yes, I _did_ disable cleancache. I could see where having > cleancache enabled could explain the difference in results. Sorry to beat a dead horse, but I meant to report this earlier in the week and got tied up by other things. I finally got my test scaffold set up earlier this week to try to reproduce my "bad" numbers with the RHEL6-ish config file. I found that with "make -j28" and "make -j32" I experienced __DATA CORRUPTION__. This was repeatable. The type of error led me to believe that the problem was due to concurrency of cleancache reclaim. I did not try with cleancache disabled to prove/support this theory but it is consistent with the fact that you (Seth) have not seen a similar problem and has disabled cleancache. While this problem is most likely in my code and I am suitably chagrined, it re-emphasizes the fact that the current zcache in staging is 20-month old "demo" code. The proposed new zcache codebase handles concurrency much more effectively. I'll be away from email for a few days now. Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] Subject: Re: [PATCH 0/4] promote zcache from staging On 08/09/2012 03:20 PM, Dan Magenheimer wrote I also wonder if you have anything else unusual in your test setup, such as a fast swap disk (mine is a partition on the same rotating disk as source and target of the kernel build, the default install for a RHEL6 system)? I'm using a normal SATA HDD with two partitions, one for swap and the other an ext3 filesystem with the kernel source. Or have you disabled cleancache? Yes, I _did_ disable cleancache. I could see where having cleancache enabled could explain the difference in results. Sorry to beat a dead horse, but I meant to report this earlier in the week and got tied up by other things. I finally got my test scaffold set up earlier this week to try to reproduce my bad numbers with the RHEL6-ish config file. I found that with make -j28 and make -j32 I experienced __DATA CORRUPTION__. This was repeatable. The type of error led me to believe that the problem was due to concurrency of cleancache reclaim. I did not try with cleancache disabled to prove/support this theory but it is consistent with the fact that you (Seth) have not seen a similar problem and has disabled cleancache. While this problem is most likely in my code and I am suitably chagrined, it re-emphasizes the fact that the current zcache in staging is 20-month old demo code. The proposed new zcache codebase handles concurrency much more effectively. I'll be away from email for a few days now. Dan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On 08/17/2012 05:21 PM, Dan Magenheimer wrote: From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] Subject: Re: [PATCH 0/4] promote zcache from staging On 08/09/2012 03:20 PM, Dan Magenheimer wrote I also wonder if you have anything else unusual in your test setup, such as a fast swap disk (mine is a partition on the same rotating disk as source and target of the kernel build, the default install for a RHEL6 system)? I'm using a normal SATA HDD with two partitions, one for swap and the other an ext3 filesystem with the kernel source. Or have you disabled cleancache? Yes, I _did_ disable cleancache. I could see where having cleancache enabled could explain the difference in results. Sorry to beat a dead horse, but I meant to report this earlier in the week and got tied up by other things. I finally got my test scaffold set up earlier this week to try to reproduce my bad numbers with the RHEL6-ish config file. I found that with make -j28 and make -j32 I experienced __DATA CORRUPTION__. This was repeatable. I actually hit this for the first time a few hours ago when I was running performance for your rewrite. I didn't know what to make of it yet. The 24-thread kernel build failed when both frontswap and cleancache were enabled. The type of error led me to believe that the problem was due to concurrency of cleancache reclaim. I did not try with cleancache disabled to prove/support this theory but it is consistent with the fact that you (Seth) have not seen a similar problem and has disabled cleancache. While this problem is most likely in my code and I am suitably chagrined, it re-emphasizes the fact that the current zcache in staging is 20-month old demo code. The proposed new zcache codebase handles concurrency much more effectively. I imagine this can be solved without rewriting the entire codebase. If your new code contains a fix for this, can we just pull it as a single patch? Seth -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On 08/15/2012 04:38 AM, Konrad Rzeszutek Wilk wrote: > On Fri, Aug 10, 2012 at 01:14:01PM -0500, Seth Jennings wrote: >> On 08/09/2012 03:20 PM, Dan Magenheimer wrote >>> I also wonder if you have anything else unusual in your >>> test setup, such as a fast swap disk (mine is a partition >>> on the same rotating disk as source and target of the kernel build, >>> the default install for a RHEL6 system)? >> >> I'm using a normal SATA HDD with two partitions, one for >> swap and the other an ext3 filesystem with the kernel source. >> >>> Or have you disabled cleancache? >> >> Yes, I _did_ disable cleancache. I could see where having >> cleancache enabled could explain the difference in results. > > Why did you disable the cleancache? Having both (cleancache > to compress fs data) and frontswap (to compress swap data) is the > goal - while you turned one of its sources off. I excluded cleancache to reduce interference/noise from the benchmarking results. For this particular workload, cleancache doesn't make a lot of sense since it will steal pages that could otherwise be used for storing frontswap pages to prevent swapin/swapout I/O. In a test run with both enabled, I found that it didn't make much difference under moderate to extreme memory pressure. Both resulted in about 55% I/O reduction. However, on light memory pressure with 8 and 12 threads, it lowered the I/O reduction ability of zcache to roughly 0 compared to ~20% I/O reduction without cleancache. In short, cleancache only had the power to harm in this case, so I didn't enable it. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On Fri, Aug 10, 2012 at 01:14:01PM -0500, Seth Jennings wrote: > On 08/09/2012 03:20 PM, Dan Magenheimer wrote > > I also wonder if you have anything else unusual in your > > test setup, such as a fast swap disk (mine is a partition > > on the same rotating disk as source and target of the kernel build, > > the default install for a RHEL6 system)? > > I'm using a normal SATA HDD with two partitions, one for > swap and the other an ext3 filesystem with the kernel source. > > > Or have you disabled cleancache? > > Yes, I _did_ disable cleancache. I could see where having > cleancache enabled could explain the difference in results. Why did you disable the cleancache? Having both (cleancache to compress fs data) and frontswap (to compress swap data) is the goal - while you turned one of its sources off. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On Fri, Aug 10, 2012 at 01:14:01PM -0500, Seth Jennings wrote: On 08/09/2012 03:20 PM, Dan Magenheimer wrote I also wonder if you have anything else unusual in your test setup, such as a fast swap disk (mine is a partition on the same rotating disk as source and target of the kernel build, the default install for a RHEL6 system)? I'm using a normal SATA HDD with two partitions, one for swap and the other an ext3 filesystem with the kernel source. Or have you disabled cleancache? Yes, I _did_ disable cleancache. I could see where having cleancache enabled could explain the difference in results. Why did you disable the cleancache? Having both (cleancache to compress fs data) and frontswap (to compress swap data) is the goal - while you turned one of its sources off. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On 08/15/2012 04:38 AM, Konrad Rzeszutek Wilk wrote: On Fri, Aug 10, 2012 at 01:14:01PM -0500, Seth Jennings wrote: On 08/09/2012 03:20 PM, Dan Magenheimer wrote I also wonder if you have anything else unusual in your test setup, such as a fast swap disk (mine is a partition on the same rotating disk as source and target of the kernel build, the default install for a RHEL6 system)? I'm using a normal SATA HDD with two partitions, one for swap and the other an ext3 filesystem with the kernel source. Or have you disabled cleancache? Yes, I _did_ disable cleancache. I could see where having cleancache enabled could explain the difference in results. Why did you disable the cleancache? Having both (cleancache to compress fs data) and frontswap (to compress swap data) is the goal - while you turned one of its sources off. I excluded cleancache to reduce interference/noise from the benchmarking results. For this particular workload, cleancache doesn't make a lot of sense since it will steal pages that could otherwise be used for storing frontswap pages to prevent swapin/swapout I/O. In a test run with both enabled, I found that it didn't make much difference under moderate to extreme memory pressure. Both resulted in about 55% I/O reduction. However, on light memory pressure with 8 and 12 threads, it lowered the I/O reduction ability of zcache to roughly 0 compared to ~20% I/O reduction without cleancache. In short, cleancache only had the power to harm in this case, so I didn't enable it. Seth -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
Hi Seth, On Tue, Aug 14, 2012 at 05:18:57PM -0500, Seth Jennings wrote: > On 07/27/2012 01:18 PM, Seth Jennings wrote: > > zcache is the remaining piece of code required to support in-kernel > > memory compression. The other two features, cleancache and frontswap, > > have been promoted to mainline in 3.0 and 3.5. This patchset > > promotes zcache from the staging tree to mainline. > > > > Based on the level of activity and contributions we're seeing from a > > diverse set of people and interests, I think zcache has matured to the > > point where it makes sense to promote this out of staging. > > I am wondering if there is any more discussion to be had on > the topic of promoting zcache. The discussion got dominated > by performance concerns, but hopefully my latest performance > metrics have alleviated those concerns for most and shown > the continuing value of zcache in both I/O and runtime savings. > > I'm not saying that zcache development is complete by any > means. There are still many improvements that can be made. > I'm just saying that I believe it is stable and beneficial > enough to leave the staging tree. > > Seth I want to do some clean up on zcache but I'm okay after it is promoted if Andrew merge it. But I'm not sure he doesn't mind it due to not good code quality which includes not enough comment, not good variable/function name, many code duplication of ramster). Anyway, I think we should unify common code between zcache and ramster before promoting at least. Otherwise, it would make code refactoring hard because we always have to touch both side for just a clean up. It means zcache contributor for the clean up should know well ramster too and it's not desirable. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On 07/27/2012 01:18 PM, Seth Jennings wrote: > zcache is the remaining piece of code required to support in-kernel > memory compression. The other two features, cleancache and frontswap, > have been promoted to mainline in 3.0 and 3.5. This patchset > promotes zcache from the staging tree to mainline. > > Based on the level of activity and contributions we're seeing from a > diverse set of people and interests, I think zcache has matured to the > point where it makes sense to promote this out of staging. I am wondering if there is any more discussion to be had on the topic of promoting zcache. The discussion got dominated by performance concerns, but hopefully my latest performance metrics have alleviated those concerns for most and shown the continuing value of zcache in both I/O and runtime savings. I'm not saying that zcache development is complete by any means. There are still many improvements that can be made. I'm just saying that I believe it is stable and beneficial enough to leave the staging tree. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On 07/27/2012 01:18 PM, Seth Jennings wrote: zcache is the remaining piece of code required to support in-kernel memory compression. The other two features, cleancache and frontswap, have been promoted to mainline in 3.0 and 3.5. This patchset promotes zcache from the staging tree to mainline. Based on the level of activity and contributions we're seeing from a diverse set of people and interests, I think zcache has matured to the point where it makes sense to promote this out of staging. I am wondering if there is any more discussion to be had on the topic of promoting zcache. The discussion got dominated by performance concerns, but hopefully my latest performance metrics have alleviated those concerns for most and shown the continuing value of zcache in both I/O and runtime savings. I'm not saying that zcache development is complete by any means. There are still many improvements that can be made. I'm just saying that I believe it is stable and beneficial enough to leave the staging tree. Seth -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
Hi Seth, On Tue, Aug 14, 2012 at 05:18:57PM -0500, Seth Jennings wrote: On 07/27/2012 01:18 PM, Seth Jennings wrote: zcache is the remaining piece of code required to support in-kernel memory compression. The other two features, cleancache and frontswap, have been promoted to mainline in 3.0 and 3.5. This patchset promotes zcache from the staging tree to mainline. Based on the level of activity and contributions we're seeing from a diverse set of people and interests, I think zcache has matured to the point where it makes sense to promote this out of staging. I am wondering if there is any more discussion to be had on the topic of promoting zcache. The discussion got dominated by performance concerns, but hopefully my latest performance metrics have alleviated those concerns for most and shown the continuing value of zcache in both I/O and runtime savings. I'm not saying that zcache development is complete by any means. There are still many improvements that can be made. I'm just saying that I believe it is stable and beneficial enough to leave the staging tree. Seth I want to do some clean up on zcache but I'm okay after it is promoted if Andrew merge it. But I'm not sure he doesn't mind it due to not good code quality which includes not enough comment, not good variable/function name, many code duplication of ramster). Anyway, I think we should unify common code between zcache and ramster before promoting at least. Otherwise, it would make code refactoring hard because we always have to touch both side for just a clean up. It means zcache contributor for the clean up should know well ramster too and it's not desirable. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On 08/09/2012 03:20 PM, Dan Magenheimer wrote > I also wonder if you have anything else unusual in your > test setup, such as a fast swap disk (mine is a partition > on the same rotating disk as source and target of the kernel build, > the default install for a RHEL6 system)? I'm using a normal SATA HDD with two partitions, one for swap and the other an ext3 filesystem with the kernel source. > Or have you disabled cleancache? Yes, I _did_ disable cleancache. I could see where having cleancache enabled could explain the difference in results. > Or have you changed any sysfs parameters or > other kernel files? No. > And are you using 512M of physical memory or relying on > kernel boot parameters to reduce visible memory Limited with mem=512M boot parameter. > ... and > if the latter have you confirmed with /proc/meminfo? Yes, confirmed. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On 08/09/2012 03:20 PM, Dan Magenheimer wrote I also wonder if you have anything else unusual in your test setup, such as a fast swap disk (mine is a partition on the same rotating disk as source and target of the kernel build, the default install for a RHEL6 system)? I'm using a normal SATA HDD with two partitions, one for swap and the other an ext3 filesystem with the kernel source. Or have you disabled cleancache? Yes, I _did_ disable cleancache. I could see where having cleancache enabled could explain the difference in results. Or have you changed any sysfs parameters or other kernel files? No. And are you using 512M of physical memory or relying on kernel boot parameters to reduce visible memory Limited with mem=512M boot parameter. ... and if the latter have you confirmed with /proc/meminfo? Yes, confirmed. Seth -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > Subject: Re: [PATCH 0/4] promote zcache from staging > > On 08/07/2012 03:23 PM, Seth Jennings wrote: > > On 07/27/2012 01:18 PM, Seth Jennings wrote: > >> Some benchmarking numbers demonstrating the I/O saving that can be had > >> with zcache: > >> > >> https://lkml.org/lkml/2012/3/22/383 > > > > There was concern that kernel changes external to zcache since v3.3 may > > have mitigated the benefit of zcache. So I re-ran my kernel building > > benchmark and confirmed that zcache is still providing I/O and runtime > > savings. > > There was a request made to test with even greater memory pressure to > demonstrate that, at some unknown point, zcache doesn't have real > problems. So I continued out to 32 threads: Hi Seth -- Thanks for continuing with running the 24-32 thread benchmarks. > Runtime (in seconds) > N normal zcache %change > 4 126 127 1% > threads, even though the absolute runtime is suboptimal due to the > extreme memory pressure. I am not in a position right now to reproduce your results or mine (due to a house move which is limiting my time and access to my test machines, plus two presentations later this month at Linuxcon NA and Plumbers) but I still don't think you've really saturated the cache, which is when the extreme memory pressure issues will show up in zcache. I suspect that adding more threads to a minimal kernel compile doesn't increase the memory pressure as much as I was seeing, so you're not seeing what I was seeing: the zcache number climb to as much as 150% WORSE than non-zcache. In various experiments trying variations, I have seen four-fold degradations and worse. My test case is a kernel compile using a full OL kernel config file, which is roughly equivalent to a RHEL6 config. Compiling this kernel, using similar hardware, I have never seen a runtime less than ~800 seconds for any value of N. I suspect that my test case, having much more source to compile, causes the N threads in a "make -jN" each have more work to do, in parallel. Since your test harness is obviously all set up, would you be willing to reproduce your/my non-zcache/zcache runs with a RHEL6 config file and publish the results (using a 3.5 zcache)? IIRC, the really bad zcache results starting showing up at N=24. I also wonder if you have anything else unusual in your test setup, such as a fast swap disk (mine is a partition on the same rotating disk as source and target of the kernel build, the default install for a RHEL6 system)? Or have you disabled cleancache? Or have you changed any sysfs parameters or other kernel files? Also, whether zcache or non-zcache, I've noticed that the runtime of this workload when swapping can vary by as much as 30-40%, so it would be wise to take at least three samples to ensure a statistically valid comparison. And are you using 512M of physical memory or relying on kernel boot parameters to reduce visible memory... and if the latter have you confirmed with /proc/meminfo? Obviously, I'm baffled at the difference in our observations. While I am always willing to admit that my numbers may be wrong, I still can't imagine why you are in such a hurry to promote zcache when these questions are looming. Would you care to explain why? It seems reckless to me, and unlike the IBM behavior I expect, so I really wonder about the motivation. My goal is very simple: "First do no harm". I don't think zcache should be enabled for distros (and users) until we can reasonably demonstrate that running a workload with zcache is never substantially worse than running the same workload without zcache. If you can tell your customer: "Yes, always enable zcache", great! But if you have to tell your customer: "It depends on the workload, enable it if it works for you, disable it otherwise", then zcache will get a bad reputation, and will/should never be enabled in a reputable non-hobbyist distro. I fear the "demo" zcache will get a bad reputation so prefer to delay promotion while there is serious doubt about whether "harm" may occur. Last, you've never explained what problems zcache solves for you that zram does not. With Minchan pushing for the promotion of zram+zsmalloc, does zram solve your problem? Another alternative might be to promote zcache as "demozcache" (i.e. fork it for now). It's hard to identify a reasonable compromise when you are just saying "Gotta promote zcache NOW!" and not explaining the problem you are trying to solve or motivations behind it. OK, Seth, I think all my cards are on the table. Where's yours? (And, hello, is anyone else following this anyway? :-) Thanks, Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On 08/07/2012 03:23 PM, Seth Jennings wrote: > On 07/27/2012 01:18 PM, Seth Jennings wrote: >> Some benchmarking numbers demonstrating the I/O saving that can be had >> with zcache: >> >> https://lkml.org/lkml/2012/3/22/383 > > There was concern that kernel changes external to zcache since v3.3 may > have mitigated the benefit of zcache. So I re-ran my kernel building > benchmark and confirmed that zcache is still providing I/O and runtime > savings. There was a request made to test with even greater memory pressure to demonstrate that, at some unknown point, zcache doesn't have real problems. So I continued out to 32 threads: N=4..20 is the same data as before except for the pswpin values. I found a mistake in the way I computed pswpin that changed those values slightly. However, this didn't change the overall trend. I also inverted the %change fields since it is a percent change vs the normal case. I/O (in pages) normal zcache change N pswpin pswpout majflt I/O sum pswpin pswpout majflt I/O sum %I/O 4 0 2 211621180 0 212521250% 8 0 575 224428190 4 22192223-21% 12 19794038322692431269251938717659-17% 16 21568 47278 942678272 777015598 937232740 -58% 20 50307 127797 15039 193143 20224 40634 17975 78833 -59% 24 186278 364809 45052 596139 47406 90489 30877 168772 -72% 28 274734 777815 53112 1105661 134981 307346 63480 505807 -54% 32 988530 2002087 168662 3159279 324801 723385 140288 1188474 -62% Runtime (in seconds) N normal zcache %change 4 126 127 1% 8 124 124 0% 12 131 133 2% 16 189 156 -17% 20 261 235 -10% 24 513 288 -44% 28 556 434 -22% 32 1463745 -49% %CPU utilization (out of 400% on 4 cpus) N normal zcache %change 4 254 253 0% 8 261 263 1% 12 250 248 -1% 16 173 211 22% 20 124 140 13% 24 64 114 78% 28 59 76 29% 32 23 45 96% The ~60% I/O savings holds even out to 32 threads, at which point the non-zcache case has 12GB of I/O and is taking 12x longer to complete. Additionally, the runtime savings increases significantly beyond 20 threads, even though the absolute runtime is suboptimal due to the extreme memory pressure. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On 08/07/2012 03:23 PM, Seth Jennings wrote: On 07/27/2012 01:18 PM, Seth Jennings wrote: Some benchmarking numbers demonstrating the I/O saving that can be had with zcache: https://lkml.org/lkml/2012/3/22/383 There was concern that kernel changes external to zcache since v3.3 may have mitigated the benefit of zcache. So I re-ran my kernel building benchmark and confirmed that zcache is still providing I/O and runtime savings. There was a request made to test with even greater memory pressure to demonstrate that, at some unknown point, zcache doesn't have real problems. So I continued out to 32 threads: N=4..20 is the same data as before except for the pswpin values. I found a mistake in the way I computed pswpin that changed those values slightly. However, this didn't change the overall trend. I also inverted the %change fields since it is a percent change vs the normal case. I/O (in pages) normal zcache change N pswpin pswpout majflt I/O sum pswpin pswpout majflt I/O sum %I/O 4 0 2 211621180 0 212521250% 8 0 575 224428190 4 22192223-21% 12 19794038322692431269251938717659-17% 16 21568 47278 942678272 777015598 937232740 -58% 20 50307 127797 15039 193143 20224 40634 17975 78833 -59% 24 186278 364809 45052 596139 47406 90489 30877 168772 -72% 28 274734 777815 53112 1105661 134981 307346 63480 505807 -54% 32 988530 2002087 168662 3159279 324801 723385 140288 1188474 -62% Runtime (in seconds) N normal zcache %change 4 126 127 1% 8 124 124 0% 12 131 133 2% 16 189 156 -17% 20 261 235 -10% 24 513 288 -44% 28 556 434 -22% 32 1463745 -49% %CPU utilization (out of 400% on 4 cpus) N normal zcache %change 4 254 253 0% 8 261 263 1% 12 250 248 -1% 16 173 211 22% 20 124 140 13% 24 64 114 78% 28 59 76 29% 32 23 45 96% The ~60% I/O savings holds even out to 32 threads, at which point the non-zcache case has 12GB of I/O and is taking 12x longer to complete. Additionally, the runtime savings increases significantly beyond 20 threads, even though the absolute runtime is suboptimal due to the extreme memory pressure. Seth -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] Subject: Re: [PATCH 0/4] promote zcache from staging On 08/07/2012 03:23 PM, Seth Jennings wrote: On 07/27/2012 01:18 PM, Seth Jennings wrote: Some benchmarking numbers demonstrating the I/O saving that can be had with zcache: https://lkml.org/lkml/2012/3/22/383 There was concern that kernel changes external to zcache since v3.3 may have mitigated the benefit of zcache. So I re-ran my kernel building benchmark and confirmed that zcache is still providing I/O and runtime savings. There was a request made to test with even greater memory pressure to demonstrate that, at some unknown point, zcache doesn't have real problems. So I continued out to 32 threads: Hi Seth -- Thanks for continuing with running the 24-32 thread benchmarks. Runtime (in seconds) N normal zcache %change 4 126 127 1% threads, even though the absolute runtime is suboptimal due to the extreme memory pressure. I am not in a position right now to reproduce your results or mine (due to a house move which is limiting my time and access to my test machines, plus two presentations later this month at Linuxcon NA and Plumbers) but I still don't think you've really saturated the cache, which is when the extreme memory pressure issues will show up in zcache. I suspect that adding more threads to a minimal kernel compile doesn't increase the memory pressure as much as I was seeing, so you're not seeing what I was seeing: the zcache number climb to as much as 150% WORSE than non-zcache. In various experiments trying variations, I have seen four-fold degradations and worse. My test case is a kernel compile using a full OL kernel config file, which is roughly equivalent to a RHEL6 config. Compiling this kernel, using similar hardware, I have never seen a runtime less than ~800 seconds for any value of N. I suspect that my test case, having much more source to compile, causes the N threads in a make -jN each have more work to do, in parallel. Since your test harness is obviously all set up, would you be willing to reproduce your/my non-zcache/zcache runs with a RHEL6 config file and publish the results (using a 3.5 zcache)? IIRC, the really bad zcache results starting showing up at N=24. I also wonder if you have anything else unusual in your test setup, such as a fast swap disk (mine is a partition on the same rotating disk as source and target of the kernel build, the default install for a RHEL6 system)? Or have you disabled cleancache? Or have you changed any sysfs parameters or other kernel files? Also, whether zcache or non-zcache, I've noticed that the runtime of this workload when swapping can vary by as much as 30-40%, so it would be wise to take at least three samples to ensure a statistically valid comparison. And are you using 512M of physical memory or relying on kernel boot parameters to reduce visible memory... and if the latter have you confirmed with /proc/meminfo? Obviously, I'm baffled at the difference in our observations. While I am always willing to admit that my numbers may be wrong, I still can't imagine why you are in such a hurry to promote zcache when these questions are looming. Would you care to explain why? It seems reckless to me, and unlike the IBM behavior I expect, so I really wonder about the motivation. My goal is very simple: First do no harm. I don't think zcache should be enabled for distros (and users) until we can reasonably demonstrate that running a workload with zcache is never substantially worse than running the same workload without zcache. If you can tell your customer: Yes, always enable zcache, great! But if you have to tell your customer: It depends on the workload, enable it if it works for you, disable it otherwise, then zcache will get a bad reputation, and will/should never be enabled in a reputable non-hobbyist distro. I fear the demo zcache will get a bad reputation so prefer to delay promotion while there is serious doubt about whether harm may occur. Last, you've never explained what problems zcache solves for you that zram does not. With Minchan pushing for the promotion of zram+zsmalloc, does zram solve your problem? Another alternative might be to promote zcache as demozcache (i.e. fork it for now). It's hard to identify a reasonable compromise when you are just saying Gotta promote zcache NOW! and not explaining the problem you are trying to solve or motivations behind it. OK, Seth, I think all my cards are on the table. Where's yours? (And, hello, is anyone else following this anyway? :-) Thanks, Dan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] Hi Seth -- Good discussion. Even though we disagree, I appreciate your enthusiasm and your good work on the kernel! > Subject: Re: [PATCH 0/4] promote zcache from staging > > On 08/07/2012 04:47 PM, Dan Magenheimer wrote: > > I notice your original published benchmarks [1] include > > N=24, N=28, and N=32, but these updated results do not. Are you planning > > on completing the runs? Second, I now see the numbers I originally > > published for what I thought was the same benchmark as yours are actually > > an order of magnitude larger (in sec) than yours. I didn't notice > > this in March because we were focused on the percent improvement, not > > the raw measurements. Since the hardware is highly similar, I suspect > > it is not a hardware difference but instead that you are compiling > > a much smaller kernel. In other words, your test case is much > > smaller, and so exercises zcache much less. My test case compiles > > a full enterprise kernel... what is yours doing? > > I am doing a minimal kernel build for my local hardware > configuration. > > With the reduction in RAM, 1GB to 512MB, I didn't need to do > test runs with >20 threads to find the peak of the benefit > curve at 16 threads. Past that, zcache is saturated and I'd > just be burning up my disk. I think that's exactly what I said in a snippet of my response that you deleted. A cache needs to work well both when it is non-full and when it is full. You are only demonstrating that it works well when it is non-full. When it is "saturated", bad things can happen. Finding the "peak of the benefit" is only half the work of benchmarking. So it appears you are trying to prove your point by showing the workloads that look good, while _not_ showing the workloads that look bad, and then claiming you don't care about those bad workloads anyway. > Also, I provide the magnitude numbers (pages, seconds) just > to show my source data. The %change numbers are the real > results as they remove build size as a factor. You'll have to explain what you mean because, if I understand correctly, this is just not true. Different build sizes definitely affect memory management differently, just as different values of N (for make -jN) have an effect. > > At LSFMM, Andrea > > Arcangeli pointed out that zcache, for frontswap pages, has no "writeback" > > capabilities and, when it is full, it simply rejects further attempts > > to put data in its cache. He said this is unacceptable for KVM and I > > agreed that it was a flaw that needed to be fixed before zcache should > > be promoted. > > KVM (in-tree) is not a current user of zcache. While the > use cases of possible future zcache users should be > considered, I don't think they can be used to prevent promotion. That wasn't my point. Andrea identified the flaw as an issue of zcache. > > A second flaw is that the "demo" zcache has no concept of LRU for > > either cleancache or frontswap pages, or ability to reclaim pageframes > > at all for frontswap pages. > ... > > > > A third flaw is that the "demo" version has a very poor policy to > > determine what pages are "admitted". > ... > > > > I can add more issues to the list, but will stop here. > > All of the flaws you list do not prevent zcache from being > beneficial right now, as my results demonstrate. Therefore, > the flaws listed are really potential improvements and can > be done in mainline after promotion. Even if large changes > are required to make these improvements, they can be made in > mainline in an incremental and public way. Your results only demonstrate that zcache is beneficial on the workloads that you chose to present. But using the same workload with slightly different parameters (-jN or compiling a larger kernel), zcache can be _detrimental_, and you've chosen to not measure or present those cases, even though you did measure and present some of those cases in your first benchmark runs posted in March (on an earlier kernel). I can only speak for myself, but this appears disingenuous to me. Sorry, but FWIW my vote is still a NACK. IMHO zcache needs major work before it should be promoted, and I think we should be spending the time fixing the known flaws rather than arguing about promoting "demo" code. Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On 08/07/2012 04:47 PM, Dan Magenheimer wrote: > I notice your original published benchmarks [1] include > N=24, N=28, and N=32, but these updated results do not. Are you planning > on completing the runs? Second, I now see the numbers I originally > published for what I thought was the same benchmark as yours are actually > an order of magnitude larger (in sec) than yours. I didn't notice > this in March because we were focused on the percent improvement, not > the raw measurements. Since the hardware is highly similar, I suspect > it is not a hardware difference but instead that you are compiling > a much smaller kernel. In other words, your test case is much > smaller, and so exercises zcache much less. My test case compiles > a full enterprise kernel... what is yours doing? I am doing a minimal kernel build for my local hardware configuration. With the reduction in RAM, 1GB to 512MB, I didn't need to do test runs with >20 threads to find the peak of the benefit curve at 16 threads. Past that, zcache is saturated and I'd just be burning up my disk. I'm already swapping out about 500MB (i.e. RAM size) in the 20 thread non-zcache case. Also, I provide the magnitude numbers (pages, seconds) just to show my source data. The %change numbers are the real results as they remove build size as a factor. > At LSFMM, Andrea > Arcangeli pointed out that zcache, for frontswap pages, has no "writeback" > capabilities and, when it is full, it simply rejects further attempts > to put data in its cache. He said this is unacceptable for KVM and I > agreed that it was a flaw that needed to be fixed before zcache should > be promoted. KVM (in-tree) is not a current user of zcache. While the use cases of possible future zcache users should be considered, I don't think they can be used to prevent promotion. > A second flaw is that the "demo" zcache has no concept of LRU for > either cleancache or frontswap pages, or ability to reclaim pageframes > at all for frontswap pages. ... > > A third flaw is that the "demo" version has a very poor policy to > determine what pages are "admitted". ... > > I can add more issues to the list, but will stop here. All of the flaws you list do not prevent zcache from being beneficial right now, as my results demonstrate. Therefore, the flaws listed are really potential improvements and can be done in mainline after promotion. Even if large changes are required to make these improvements, they can be made in mainline in an incremental and public way. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On 08/07/2012 04:47 PM, Dan Magenheimer wrote: I notice your original published benchmarks [1] include N=24, N=28, and N=32, but these updated results do not. Are you planning on completing the runs? Second, I now see the numbers I originally published for what I thought was the same benchmark as yours are actually an order of magnitude larger (in sec) than yours. I didn't notice this in March because we were focused on the percent improvement, not the raw measurements. Since the hardware is highly similar, I suspect it is not a hardware difference but instead that you are compiling a much smaller kernel. In other words, your test case is much smaller, and so exercises zcache much less. My test case compiles a full enterprise kernel... what is yours doing? I am doing a minimal kernel build for my local hardware configuration. With the reduction in RAM, 1GB to 512MB, I didn't need to do test runs with 20 threads to find the peak of the benefit curve at 16 threads. Past that, zcache is saturated and I'd just be burning up my disk. I'm already swapping out about 500MB (i.e. RAM size) in the 20 thread non-zcache case. Also, I provide the magnitude numbers (pages, seconds) just to show my source data. The %change numbers are the real results as they remove build size as a factor. At LSFMM, Andrea Arcangeli pointed out that zcache, for frontswap pages, has no writeback capabilities and, when it is full, it simply rejects further attempts to put data in its cache. He said this is unacceptable for KVM and I agreed that it was a flaw that needed to be fixed before zcache should be promoted. KVM (in-tree) is not a current user of zcache. While the use cases of possible future zcache users should be considered, I don't think they can be used to prevent promotion. A second flaw is that the demo zcache has no concept of LRU for either cleancache or frontswap pages, or ability to reclaim pageframes at all for frontswap pages. ... A third flaw is that the demo version has a very poor policy to determine what pages are admitted. ... I can add more issues to the list, but will stop here. All of the flaws you list do not prevent zcache from being beneficial right now, as my results demonstrate. Therefore, the flaws listed are really potential improvements and can be done in mainline after promotion. Even if large changes are required to make these improvements, they can be made in mainline in an incremental and public way. Seth -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] Hi Seth -- Good discussion. Even though we disagree, I appreciate your enthusiasm and your good work on the kernel! Subject: Re: [PATCH 0/4] promote zcache from staging On 08/07/2012 04:47 PM, Dan Magenheimer wrote: I notice your original published benchmarks [1] include N=24, N=28, and N=32, but these updated results do not. Are you planning on completing the runs? Second, I now see the numbers I originally published for what I thought was the same benchmark as yours are actually an order of magnitude larger (in sec) than yours. I didn't notice this in March because we were focused on the percent improvement, not the raw measurements. Since the hardware is highly similar, I suspect it is not a hardware difference but instead that you are compiling a much smaller kernel. In other words, your test case is much smaller, and so exercises zcache much less. My test case compiles a full enterprise kernel... what is yours doing? I am doing a minimal kernel build for my local hardware configuration. With the reduction in RAM, 1GB to 512MB, I didn't need to do test runs with 20 threads to find the peak of the benefit curve at 16 threads. Past that, zcache is saturated and I'd just be burning up my disk. I think that's exactly what I said in a snippet of my response that you deleted. A cache needs to work well both when it is non-full and when it is full. You are only demonstrating that it works well when it is non-full. When it is saturated, bad things can happen. Finding the peak of the benefit is only half the work of benchmarking. So it appears you are trying to prove your point by showing the workloads that look good, while _not_ showing the workloads that look bad, and then claiming you don't care about those bad workloads anyway. Also, I provide the magnitude numbers (pages, seconds) just to show my source data. The %change numbers are the real results as they remove build size as a factor. You'll have to explain what you mean because, if I understand correctly, this is just not true. Different build sizes definitely affect memory management differently, just as different values of N (for make -jN) have an effect. At LSFMM, Andrea Arcangeli pointed out that zcache, for frontswap pages, has no writeback capabilities and, when it is full, it simply rejects further attempts to put data in its cache. He said this is unacceptable for KVM and I agreed that it was a flaw that needed to be fixed before zcache should be promoted. KVM (in-tree) is not a current user of zcache. While the use cases of possible future zcache users should be considered, I don't think they can be used to prevent promotion. That wasn't my point. Andrea identified the flaw as an issue of zcache. A second flaw is that the demo zcache has no concept of LRU for either cleancache or frontswap pages, or ability to reclaim pageframes at all for frontswap pages. ... A third flaw is that the demo version has a very poor policy to determine what pages are admitted. ... I can add more issues to the list, but will stop here. All of the flaws you list do not prevent zcache from being beneficial right now, as my results demonstrate. Therefore, the flaws listed are really potential improvements and can be done in mainline after promotion. Even if large changes are required to make these improvements, they can be made in mainline in an incremental and public way. Your results only demonstrate that zcache is beneficial on the workloads that you chose to present. But using the same workload with slightly different parameters (-jN or compiling a larger kernel), zcache can be _detrimental_, and you've chosen to not measure or present those cases, even though you did measure and present some of those cases in your first benchmark runs posted in March (on an earlier kernel). I can only speak for myself, but this appears disingenuous to me. Sorry, but FWIW my vote is still a NACK. IMHO zcache needs major work before it should be promoted, and I think we should be spending the time fixing the known flaws rather than arguing about promoting demo code. Dan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > Subject: Re: [PATCH 0/4] promote zcache from staging > > On 07/27/2012 01:18 PM, Seth Jennings wrote: > > Some benchmarking numbers demonstrating the I/O saving that can be had > > with zcache: > > > > https://lkml.org/lkml/2012/3/22/383 > > There was concern that kernel changes external to zcache since v3.3 may > have mitigated the benefit of zcache. So I re-ran my kernel building > benchmark and confirmed that zcache is still providing I/O and runtime > savings. Hi Seth -- Thanks for re-running your tests. I have a couple of concerns and hope that you, and other interested parties, will read all the way through my lengthy response. The zcache issues I have seen in recent kernels arise when zcache gets "full". I notice your original published benchmarks [1] include N=24, N=28, and N=32, but these updated results do not. Are you planning on completing the runs? Second, I now see the numbers I originally published for what I thought was the same benchmark as yours are actually an order of magnitude larger (in sec) than yours. I didn't notice this in March because we were focused on the percent improvement, not the raw measurements. Since the hardware is highly similar, I suspect it is not a hardware difference but instead that you are compiling a much smaller kernel. In other words, your test case is much smaller, and so exercises zcache much less. My test case compiles a full enterprise kernel... what is yours doing? IMHO, any cache in computer science needs to be measured both when it is not-yet-full and when it is full. The "demo" zcache in staging works very well before it is full and I think our benchmarking in March and your re-run benchmarks demonstrate that. At LSFMM, Andrea Arcangeli pointed out that zcache, for frontswap pages, has no "writeback" capabilities and, when it is full, it simply rejects further attempts to put data in its cache. He said this is unacceptable for KVM and I agreed that it was a flaw that needed to be fixed before zcache should be promoted. When I tested zcache for this, I found that not only was he right, but that zcache could not be fixed without a major rewrite. This is one of the "fundamental flaws" of the "demo" zcache, but the new code base allows for this to be fixed. A second flaw is that the "demo" zcache has no concept of LRU for either cleancache or frontswap pages, or ability to reclaim pageframes at all for frontswap pages. (And for cleancache, pageframe reclaim is semi-random). As I've noted in other threads, this may be impossible to implement/fix with zsmalloc, and zsmalloc's author Nitin Gupta has agreed, but the new code base implements all of this with zbud. One can argue that LRU is not a requirement for zcache, but a long history of operating systems theory would suggest otherwise. A third flaw is that the "demo" version has a very poor policy to determine what pages are "admitted". The demo policy does take into account the total RAM in the system, but not current memory load conditions. The new code base IMHO does a better job but discussion will be in a refereed presentation at the upcoming Plumber's meeting. The fix for this flaw might be back-portable to the "demo" version so is not a showstopper in the "demo" version, but fixing it is not just a cosmetic fix. I can add more issues to the list, but will stop here. IMHO the "demo" zcache is not suitable for promotion from staging, which is why I spent over two months generating a new code base. I, perhaps more than anyone else, would like to see zcache used, by default, by real distros and customers, but I think it is premature to promote it, especially the old "demo" code. I do realize, however, that this decision is not mine alone so defer to the community to decide. Dan [1] https://lkml.org/lkml/2012/3/22/383 [2] http://lkml.indiana.edu/hypermail/linux/kernel/1203.2/02842.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On 07/27/2012 01:18 PM, Seth Jennings wrote: > Some benchmarking numbers demonstrating the I/O saving that can be had > with zcache: > > https://lkml.org/lkml/2012/3/22/383 There was concern that kernel changes external to zcache since v3.3 may have mitigated the benefit of zcache. So I re-ran my kernel building benchmark and confirmed that zcache is still providing I/O and runtime savings. Gentoo w/ kernel v3.5 (frontswap only, cleancache disabled) Quad-core i5-2500 @ 3.3GHz 512MB DDR3 1600MHz (limited with mem=512m on boot) Filesystem and swap on 80GB HDD (about 58MB/s with hdparm -t) majflt are major page faults reported by the time command pswpin/out is the delta of pswpin/out from /proc/vmstat before and after the make -jN Mind the 512MB RAM vs 1GB in my previous results. This just reduces the number of threads required to create memory pressure and removes some of the context switching noise from the results. I'm also using a single HDD instead of the RAID0 in my previous results. Each run started with with: swapoff -a swapon -a sync echo 3 > /proc/sys/vm/drop_caches I/O (in pages): normal zcache change N pswpin pswpout majflt I/O sum pswpin pswpout majflt I/O sum %I/O 4 0 2 211621180 0 212521250% 8 0 575 224428194 4 2219222721% 12 2543403832269807174825193871813817% 16 23926 47278 942680630 825215598 937233222 59% 20 50307 127797 15039 193143 20224 40634 17975 78833 59% Runtime (in seconds): N normal zcache %change 4 126 127 -1% 8 124 124 0% 12 131 133 -2% 16 189 156 17% 20 261 235 10% %CPU utilization (out of 400% on 4 cpus) N normal zcache %change 4 254 253 0% 8 261 263 -1% 12 250 248 1% 16 173 211 -22% 20 124 140 -13% There is a sweet spot at 16 threads, where zcache is improving runtime by 17% and reducing I/O by 59% (185MB) using 22% more CPU. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On Mon, Aug 06, 2012 at 09:38:16AM +0900, Minchan Kim wrote: > Hi Konrad, > > On Tue, Jul 31, 2012 at 01:51:42PM -0400, Konrad Rzeszutek Wilk wrote: > > On Tue, Jul 31, 2012 at 09:19:16AM -0700, Greg Kroah-Hartman wrote: > > > On Tue, Jul 31, 2012 at 11:58:43AM -0400, Konrad Rzeszutek Wilk wrote: > > > > So in my head I feel that it is Ok to: > > > > 1) address the concerns that zcache has before it is unstaged > > > > 2) rip out the two-engine system with a one-engine system > > > >(and see how well it behaves) > > > > 3) sysfs->debugfs as needed > > > > 4) other things as needed > > > > > > > > I think we are getting hung-up what Greg said about adding features > > > > and the two-engine->one engine could be understood as that. > > > > While I think that is part of a staging effort to clean up the > > > > existing issues. Lets see what Greg thinks. > > > > > > Greg has no idea, except I want to see the needed fixups happen before > > > new features get added. Add the new features _after_ it is out of > > > staging. > > > > I think we (that is me, Seth, Minchan, Dan) need to talk to have a good > > understanding of what each of us thinks are fixups. > > > > Would Monday Aug 6th at 1pm EST on irc.freenode.net channel #zcache work > > for people? > > 1pm EST is 2am KST(Korea Standard Time) so it's not good for me. :) > I know it's hard to adjust my time for yours so let you talk without > me. Instead, I will write it down my requirement. It's very simple and > trivial. OK, Thank you. We had a lengthy chat (full chat log attached). The summary was that we all want to promote zcache (for various reasons), but we are hang up whether we are OK unstaging it wherein it lowers the I/Os but potentially not giving large performance increase (when doing 'make -jN') or that we want both of those characteristics in. Little history: v3.3 had swap readahead patches that made the amount of pages going in swap dramatically decrease - as such the performance of zcache is not anymore amazing, but ok. Seth and Robert (and I surmise Minchan too) are very interested in zcache as its lowers the amount of I/Os but performance is secondary. Dan is interested in having less I/Os and providing a performance boost with the such workloads as 'make -jN' - in short less I/Os and better performance. Dan would like both before unstaging. The action items that came out are: - Seth posted some benchmarks - he is going to rerun them with v3.5 to see how it behaves in terms of performance (make -jN benchmark). - Robert is going to take a swing at Minchan refactor and adding comments, etc (But after we get over the hump of agreeing on the next step). - Konrad to rummage in his mbox to find any other technical objections that were raised on zcache earlier to make sure to address them. - Once Seth is finished Konrad is going to take another swing at driving this discussion - either via email, IRC or conference call. Aug 06 11:38:41 * Now talking on #zcache Aug 06 11:38:41 * cameron.freenode.net sets mode +n #zcache Aug 06 11:38:41 * cameron.freenode.net sets mode +s #zcache Aug 06 12:38:15 * sjennings (~sjennings@2001:470:1f0f:87d:e46c:7cd1:4974:640b) has joined #zcache Aug 06 12:49:12 * rcj (~rcjenn@32.97.110.59) has joined #zcache Aug 06 12:50:26 * djm1 (~djm1...@inet-hqmc03-o.oracle.com) has joined #zcache Aug 06 12:50:29Good morning Konrad, thanks for suggesting this. Aug 06 12:50:32 * darnok (~kon...@209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com) has joined #zcache Aug 06 12:50:47 hi all, first time user for freenode so I had to register, sorry to be late Aug 06 12:50:53 (this is Dan Magenheimer) Aug 06 12:51:17 djm1, I think you can be just an unregister user? Aug 06 12:51:36 rcj, Sure thinkg Aug 06 12:51:51 * darnok goes away now that the proper Konrad is in place Aug 06 12:52:08 konrad/darnok: ok, we can deal with that later, for now, "call me djm1" Aug 06 12:52:22 Sure. So I think we are all here right? Minchan couldn't make it Aug 06 12:52:38 i don't know of anyone else that was planning to come ENDING LOGGING AT Mon Aug 6 12:52:39 2012 BEGIN LOGGING AT Mon Aug 6 12:52:39 2012 Aug 06 12:52:46Sounds good Aug 06 12:52:59 * konrad nods. Aug 06 12:53:18 Let me first start by saying thank you for being able to make it. Aug 06 12:53:42 Sometimes it takes a whole bunch of iterations to setup a call but this worked out fine. Aug 06 12:53:46 * darnok has quit (Read error: Operation timed out) Aug 06 12:54:10 And also for the interest in zcache/tmem/frontswap/cleanpage/future ideas. Aug 06 12:55:11 I think we all want all the pieces completely out of staging (irregardlesss of how internally each company uses the technologies - we have been shipping it with our kernel - UEK2) Aug 06 12:55:55We do want it out of staging, for us we can't use it
Re: [PATCH 0/4] promote zcache from staging
On Mon, Aug 06, 2012 at 09:38:16AM +0900, Minchan Kim wrote: Hi Konrad, On Tue, Jul 31, 2012 at 01:51:42PM -0400, Konrad Rzeszutek Wilk wrote: On Tue, Jul 31, 2012 at 09:19:16AM -0700, Greg Kroah-Hartman wrote: On Tue, Jul 31, 2012 at 11:58:43AM -0400, Konrad Rzeszutek Wilk wrote: So in my head I feel that it is Ok to: 1) address the concerns that zcache has before it is unstaged 2) rip out the two-engine system with a one-engine system (and see how well it behaves) 3) sysfs-debugfs as needed 4) other things as needed I think we are getting hung-up what Greg said about adding features and the two-engine-one engine could be understood as that. While I think that is part of a staging effort to clean up the existing issues. Lets see what Greg thinks. Greg has no idea, except I want to see the needed fixups happen before new features get added. Add the new features _after_ it is out of staging. I think we (that is me, Seth, Minchan, Dan) need to talk to have a good understanding of what each of us thinks are fixups. Would Monday Aug 6th at 1pm EST on irc.freenode.net channel #zcache work for people? 1pm EST is 2am KST(Korea Standard Time) so it's not good for me. :) I know it's hard to adjust my time for yours so let you talk without me. Instead, I will write it down my requirement. It's very simple and trivial. OK, Thank you. We had a lengthy chat (full chat log attached). The summary was that we all want to promote zcache (for various reasons), but we are hang up whether we are OK unstaging it wherein it lowers the I/Os but potentially not giving large performance increase (when doing 'make -jN') or that we want both of those characteristics in. Little history: v3.3 had swap readahead patches that made the amount of pages going in swap dramatically decrease - as such the performance of zcache is not anymore amazing, but ok. Seth and Robert (and I surmise Minchan too) are very interested in zcache as its lowers the amount of I/Os but performance is secondary. Dan is interested in having less I/Os and providing a performance boost with the such workloads as 'make -jN' - in short less I/Os and better performance. Dan would like both before unstaging. The action items that came out are: - Seth posted some benchmarks - he is going to rerun them with v3.5 to see how it behaves in terms of performance (make -jN benchmark). - Robert is going to take a swing at Minchan refactor and adding comments, etc (But after we get over the hump of agreeing on the next step). - Konrad to rummage in his mbox to find any other technical objections that were raised on zcache earlier to make sure to address them. - Once Seth is finished Konrad is going to take another swing at driving this discussion - either via email, IRC or conference call. Aug 06 11:38:41 * Now talking on #zcache Aug 06 11:38:41 * cameron.freenode.net sets mode +n #zcache Aug 06 11:38:41 * cameron.freenode.net sets mode +s #zcache Aug 06 12:38:15 * sjennings (~sjennings@2001:470:1f0f:87d:e46c:7cd1:4974:640b) has joined #zcache Aug 06 12:49:12 * rcj (~rcjenn@32.97.110.59) has joined #zcache Aug 06 12:50:26 * djm1 (~djm1...@inet-hqmc03-o.oracle.com) has joined #zcache Aug 06 12:50:29 rcj Good morning Konrad, thanks for suggesting this. Aug 06 12:50:32 * darnok (~kon...@209-6-85-33.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com) has joined #zcache Aug 06 12:50:47 djm1 hi all, first time user for freenode so I had to register, sorry to be late Aug 06 12:50:53 djm1 (this is Dan Magenheimer) Aug 06 12:51:17 darnokdjm1, I think you can be just an unregister user? Aug 06 12:51:36 konradrcj, Sure thinkg Aug 06 12:51:51 * darnok goes away now that the proper Konrad is in place Aug 06 12:52:08 djm1 konrad/darnok: ok, we can deal with that later, for now, call me djm1 Aug 06 12:52:22 konradSure. So I think we are all here right? Minchan couldn't make it Aug 06 12:52:38 sjennings i don't know of anyone else that was planning to come ENDING LOGGING AT Mon Aug 6 12:52:39 2012 BEGIN LOGGING AT Mon Aug 6 12:52:39 2012 Aug 06 12:52:46 rcj Sounds good Aug 06 12:52:59 * konrad nods. Aug 06 12:53:18 konradLet me first start by saying thank you for being able to make it. Aug 06 12:53:42 konradSometimes it takes a whole bunch of iterations to setup a call but this worked out fine. Aug 06 12:53:46 * darnok has quit (Read error: Operation timed out) Aug 06 12:54:10 konradAnd also for the interest in zcache/tmem/frontswap/cleanpage/future ideas. Aug 06 12:55:11 konradI think we all want all the pieces completely out of staging (irregardlesss of how internally each company uses the technologies - we have been shipping it with our kernel - UEK2) Aug 06 12:55:55 rcj We do want it out of staging, for us we can't use it until it's out
Re: [PATCH 0/4] promote zcache from staging
On 07/27/2012 01:18 PM, Seth Jennings wrote: Some benchmarking numbers demonstrating the I/O saving that can be had with zcache: https://lkml.org/lkml/2012/3/22/383 There was concern that kernel changes external to zcache since v3.3 may have mitigated the benefit of zcache. So I re-ran my kernel building benchmark and confirmed that zcache is still providing I/O and runtime savings. Gentoo w/ kernel v3.5 (frontswap only, cleancache disabled) Quad-core i5-2500 @ 3.3GHz 512MB DDR3 1600MHz (limited with mem=512m on boot) Filesystem and swap on 80GB HDD (about 58MB/s with hdparm -t) majflt are major page faults reported by the time command pswpin/out is the delta of pswpin/out from /proc/vmstat before and after the make -jN Mind the 512MB RAM vs 1GB in my previous results. This just reduces the number of threads required to create memory pressure and removes some of the context switching noise from the results. I'm also using a single HDD instead of the RAID0 in my previous results. Each run started with with: swapoff -a swapon -a sync echo 3 /proc/sys/vm/drop_caches I/O (in pages): normal zcache change N pswpin pswpout majflt I/O sum pswpin pswpout majflt I/O sum %I/O 4 0 2 211621180 0 212521250% 8 0 575 224428194 4 2219222721% 12 2543403832269807174825193871813817% 16 23926 47278 942680630 825215598 937233222 59% 20 50307 127797 15039 193143 20224 40634 17975 78833 59% Runtime (in seconds): N normal zcache %change 4 126 127 -1% 8 124 124 0% 12 131 133 -2% 16 189 156 17% 20 261 235 10% %CPU utilization (out of 400% on 4 cpus) N normal zcache %change 4 254 253 0% 8 261 263 -1% 12 250 248 1% 16 173 211 -22% 20 124 140 -13% There is a sweet spot at 16 threads, where zcache is improving runtime by 17% and reducing I/O by 59% (185MB) using 22% more CPU. Seth -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] Subject: Re: [PATCH 0/4] promote zcache from staging On 07/27/2012 01:18 PM, Seth Jennings wrote: Some benchmarking numbers demonstrating the I/O saving that can be had with zcache: https://lkml.org/lkml/2012/3/22/383 There was concern that kernel changes external to zcache since v3.3 may have mitigated the benefit of zcache. So I re-ran my kernel building benchmark and confirmed that zcache is still providing I/O and runtime savings. Hi Seth -- Thanks for re-running your tests. I have a couple of concerns and hope that you, and other interested parties, will read all the way through my lengthy response. The zcache issues I have seen in recent kernels arise when zcache gets full. I notice your original published benchmarks [1] include N=24, N=28, and N=32, but these updated results do not. Are you planning on completing the runs? Second, I now see the numbers I originally published for what I thought was the same benchmark as yours are actually an order of magnitude larger (in sec) than yours. I didn't notice this in March because we were focused on the percent improvement, not the raw measurements. Since the hardware is highly similar, I suspect it is not a hardware difference but instead that you are compiling a much smaller kernel. In other words, your test case is much smaller, and so exercises zcache much less. My test case compiles a full enterprise kernel... what is yours doing? IMHO, any cache in computer science needs to be measured both when it is not-yet-full and when it is full. The demo zcache in staging works very well before it is full and I think our benchmarking in March and your re-run benchmarks demonstrate that. At LSFMM, Andrea Arcangeli pointed out that zcache, for frontswap pages, has no writeback capabilities and, when it is full, it simply rejects further attempts to put data in its cache. He said this is unacceptable for KVM and I agreed that it was a flaw that needed to be fixed before zcache should be promoted. When I tested zcache for this, I found that not only was he right, but that zcache could not be fixed without a major rewrite. This is one of the fundamental flaws of the demo zcache, but the new code base allows for this to be fixed. A second flaw is that the demo zcache has no concept of LRU for either cleancache or frontswap pages, or ability to reclaim pageframes at all for frontswap pages. (And for cleancache, pageframe reclaim is semi-random). As I've noted in other threads, this may be impossible to implement/fix with zsmalloc, and zsmalloc's author Nitin Gupta has agreed, but the new code base implements all of this with zbud. One can argue that LRU is not a requirement for zcache, but a long history of operating systems theory would suggest otherwise. A third flaw is that the demo version has a very poor policy to determine what pages are admitted. The demo policy does take into account the total RAM in the system, but not current memory load conditions. The new code base IMHO does a better job but discussion will be in a refereed presentation at the upcoming Plumber's meeting. The fix for this flaw might be back-portable to the demo version so is not a showstopper in the demo version, but fixing it is not just a cosmetic fix. I can add more issues to the list, but will stop here. IMHO the demo zcache is not suitable for promotion from staging, which is why I spent over two months generating a new code base. I, perhaps more than anyone else, would like to see zcache used, by default, by real distros and customers, but I think it is premature to promote it, especially the old demo code. I do realize, however, that this decision is not mine alone so defer to the community to decide. Dan [1] https://lkml.org/lkml/2012/3/22/383 [2] http://lkml.indiana.edu/hypermail/linux/kernel/1203.2/02842.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
Hi Dan, On Mon, Aug 06, 2012 at 09:21:22AM -0700, Dan Magenheimer wrote: > > From: Pekka Enberg [mailto:penb...@kernel.org] > > Subject: Re: [PATCH 0/4] promote zcache from staging > > > > On Mon, Aug 6, 2012 at 6:24 PM, Dan Magenheimer > > wrote: > > > IMHO, the fastest way to get the best zcache into the kernel and > > > to distros and users is to throw away the "demo" version, move forward > > > to a new solid well-designed zcache code base, and work together to > > > build on it. There's still a lot to do so I hope we can work together. > > > > I'm not convinced it's the _fastest way_. > > I guess I meant "optimal", combining "fast" and "best". > > > You're effectively > > invalidating all the work done under drivers/staging so you might end up > > in review limbo with your shiny new code... > > Fixing the fundamental design flaws will sooner or later invalidate > most (or all) of the previous testing/work anyway, won't it? Since > any kernel built with staging is "tainted" already, I feel like now > is a better time to make a major design transition. > > I suppose: > > (E) replace "demo" zcache with new code base and keep it > in staging for another cycle I go for (E). Please send your refactoring code as formal patch. Thanks. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] > Subject: Re: [PATCH 0/4] promote zcache from staging > > On Mon, Aug 06, 2012 at 09:21:22AM -0700, Dan Magenheimer wrote: > > I suppose: > > > > (E) replace "demo" zcache with new code base and keep it > > in staging for another cycle > > > > is another alternative, but I think gregkh has said no to that. > > No I have not. If you all feel that the existing code needs to be > dropped and replaced with a totally new version, that's fine with me. > It's forward progress, which is all that I ask for. > > Hope this helps, > greg k-h Hi Greg -- Cool! I guess I mistakenly assumed that your "no new features" requirement also implied "no fixes of fundamental design flaws". :-) Having option (E) should make it easier to decide the best technical solution, separate from the promotion timing and "where does it land" question. We'll get back to you soon... Thanks! Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On Mon, Aug 06, 2012 at 09:21:22AM -0700, Dan Magenheimer wrote: > I suppose: > > (E) replace "demo" zcache with new code base and keep it > in staging for another cycle > > is another alternative, but I think gregkh has said no to that. No I have not. If you all feel that the existing code needs to be dropped and replaced with a totally new version, that's fine with me. It's forward progress, which is all that I ask for. Hope this helps, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
> From: Pekka Enberg [mailto:penb...@kernel.org] > Subject: Re: [PATCH 0/4] promote zcache from staging > > On Mon, Aug 6, 2012 at 6:24 PM, Dan Magenheimer > wrote: > > IMHO, the fastest way to get the best zcache into the kernel and > > to distros and users is to throw away the "demo" version, move forward > > to a new solid well-designed zcache code base, and work together to > > build on it. There's still a lot to do so I hope we can work together. > > I'm not convinced it's the _fastest way_. I guess I meant "optimal", combining "fast" and "best". > You're effectively > invalidating all the work done under drivers/staging so you might end up > in review limbo with your shiny new code... Fixing the fundamental design flaws will sooner or later invalidate most (or all) of the previous testing/work anyway, won't it? Since any kernel built with staging is "tainted" already, I feel like now is a better time to make a major design transition. I suppose: (E) replace "demo" zcache with new code base and keep it in staging for another cycle is another alternative, but I think gregkh has said no to that. Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On Mon, Aug 6, 2012 at 6:24 PM, Dan Magenheimer wrote: > IMHO, the fastest way to get the best zcache into the kernel and > to distros and users is to throw away the "demo" version, move forward > to a new solid well-designed zcache code base, and work together to > build on it. There's still a lot to do so I hope we can work together. I'm not convinced it's the _fastest way_. You're effectively invalidating all the work done under drivers/staging so you might end up in review limbo with your shiny new code... AFAICT, your best bet is to first clean up zcache under driver/staging and get that promoted under mm/zcache.c. You can then move on to the more controversial ramster and figure out where to put the clustering code, etc. Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
> > I think we (that is me, Seth, Minchan, Dan) need to talk to have a good > > understanding of what each of us thinks are fixups. > > > > Would Monday Aug 6th at 1pm EST on irc.freenode.net channel #zcache work > > for people? > > 1pm EST is 2am KST(Korea Standard Time) so it's not good for me. :) > I know it's hard to adjust my time for yours so let you talk without > me. Instead, I will write it down my requirement. It's very simple and > trivial. > > 1) Please don't add any new feature like replace zsmalloc with zbud. >It's totally untested so it needs more time for stable POV bug, >or performance/fragementation. > > 2) Factor out common code between zcache and ramster. It should be just >clean up code and should not change current behavior. > > 3) Add lots of comment to public functions > > 4) make function/varabiel names more clearly. > > They are necessary for promotion and after promotion, > let's talk about new great features. Hi Minchan -- I hope you had a great vacation! Since we won't be able to discuss this by phone/irc, I guess I need to reply here. Let me first restate my opinion as author of zcache. The zcache in staging is really a "demo" version. It was written 21 months ago (and went into staging 16 months ago) primarily to show, at Andrew Morton's suggestion, that frontswap and cleancache had value in a normal standalone kernel (i.e. virtualization not required). When posted in early 2011 zcache was known to have some fundamental flaws in the design... that's why it went into "staging". The "demo" version in staging still has those flaws and the change from xvmalloc to zsmalloc makes one of those flaws worse. These design flaws are now fixed in the new code base I posted last week AND the new code base has improved factoring, comments and the code is properly re-merged with the zcache "fork" in ramster. We are not talking about new "features"... I have tried to back out the new features from the new code base already posted and will post them separately. So I think we have four choices: A) Try to promote zcache as is. (Seth's proposal) B) Clean up zcache with no new functionality. (Minchan's proposal above) C) New code base (in mm/tmem/) after review. (Dan's proposal) D) New code base but retrofit as a series of patches (Konrad's suggestion) Minchan, if we go with your proposal (B) are you volunteering to do the work? And if you do, doesn't it have the same issue that it is also totally untested? And, since (B) doesn't solve the fundamental design issues, are you volunteering to fix those next? And, in the meantime, doesn't this mean we have THREE versions of zcache? IMHO, the fastest way to get the best zcache into the kernel and to distros and users is to throw away the "demo" version, move forward to a new solid well-designed zcache code base, and work together to build on it. There's still a lot to do so I hope we can work together. Thanks, Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
I think we (that is me, Seth, Minchan, Dan) need to talk to have a good understanding of what each of us thinks are fixups. Would Monday Aug 6th at 1pm EST on irc.freenode.net channel #zcache work for people? 1pm EST is 2am KST(Korea Standard Time) so it's not good for me. :) I know it's hard to adjust my time for yours so let you talk without me. Instead, I will write it down my requirement. It's very simple and trivial. 1) Please don't add any new feature like replace zsmalloc with zbud. It's totally untested so it needs more time for stable POV bug, or performance/fragementation. 2) Factor out common code between zcache and ramster. It should be just clean up code and should not change current behavior. 3) Add lots of comment to public functions 4) make function/varabiel names more clearly. They are necessary for promotion and after promotion, let's talk about new great features. Hi Minchan -- I hope you had a great vacation! Since we won't be able to discuss this by phone/irc, I guess I need to reply here. Let me first restate my opinion as author of zcache. The zcache in staging is really a demo version. It was written 21 months ago (and went into staging 16 months ago) primarily to show, at Andrew Morton's suggestion, that frontswap and cleancache had value in a normal standalone kernel (i.e. virtualization not required). When posted in early 2011 zcache was known to have some fundamental flaws in the design... that's why it went into staging. The demo version in staging still has those flaws and the change from xvmalloc to zsmalloc makes one of those flaws worse. These design flaws are now fixed in the new code base I posted last week AND the new code base has improved factoring, comments and the code is properly re-merged with the zcache fork in ramster. We are not talking about new features... I have tried to back out the new features from the new code base already posted and will post them separately. So I think we have four choices: A) Try to promote zcache as is. (Seth's proposal) B) Clean up zcache with no new functionality. (Minchan's proposal above) C) New code base (in mm/tmem/) after review. (Dan's proposal) D) New code base but retrofit as a series of patches (Konrad's suggestion) Minchan, if we go with your proposal (B) are you volunteering to do the work? And if you do, doesn't it have the same issue that it is also totally untested? And, since (B) doesn't solve the fundamental design issues, are you volunteering to fix those next? And, in the meantime, doesn't this mean we have THREE versions of zcache? IMHO, the fastest way to get the best zcache into the kernel and to distros and users is to throw away the demo version, move forward to a new solid well-designed zcache code base, and work together to build on it. There's still a lot to do so I hope we can work together. Thanks, Dan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On Mon, Aug 6, 2012 at 6:24 PM, Dan Magenheimer dan.magenhei...@oracle.com wrote: IMHO, the fastest way to get the best zcache into the kernel and to distros and users is to throw away the demo version, move forward to a new solid well-designed zcache code base, and work together to build on it. There's still a lot to do so I hope we can work together. I'm not convinced it's the _fastest way_. You're effectively invalidating all the work done under drivers/staging so you might end up in review limbo with your shiny new code... AFAICT, your best bet is to first clean up zcache under driver/staging and get that promoted under mm/zcache.c. You can then move on to the more controversial ramster and figure out where to put the clustering code, etc. Pekka -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
From: Pekka Enberg [mailto:penb...@kernel.org] Subject: Re: [PATCH 0/4] promote zcache from staging On Mon, Aug 6, 2012 at 6:24 PM, Dan Magenheimer dan.magenhei...@oracle.com wrote: IMHO, the fastest way to get the best zcache into the kernel and to distros and users is to throw away the demo version, move forward to a new solid well-designed zcache code base, and work together to build on it. There's still a lot to do so I hope we can work together. I'm not convinced it's the _fastest way_. grin I guess I meant optimal, combining fast and best. You're effectively invalidating all the work done under drivers/staging so you might end up in review limbo with your shiny new code... Fixing the fundamental design flaws will sooner or later invalidate most (or all) of the previous testing/work anyway, won't it? Since any kernel built with staging is tainted already, I feel like now is a better time to make a major design transition. I suppose: (E) replace demo zcache with new code base and keep it in staging for another cycle is another alternative, but I think gregkh has said no to that. Dan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On Mon, Aug 06, 2012 at 09:21:22AM -0700, Dan Magenheimer wrote: I suppose: (E) replace demo zcache with new code base and keep it in staging for another cycle is another alternative, but I think gregkh has said no to that. No I have not. If you all feel that the existing code needs to be dropped and replaced with a totally new version, that's fine with me. It's forward progress, which is all that I ask for. Hope this helps, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] Subject: Re: [PATCH 0/4] promote zcache from staging On Mon, Aug 06, 2012 at 09:21:22AM -0700, Dan Magenheimer wrote: I suppose: (E) replace demo zcache with new code base and keep it in staging for another cycle is another alternative, but I think gregkh has said no to that. No I have not. If you all feel that the existing code needs to be dropped and replaced with a totally new version, that's fine with me. It's forward progress, which is all that I ask for. Hope this helps, greg k-h Hi Greg -- Cool! I guess I mistakenly assumed that your no new features requirement also implied no fixes of fundamental design flaws. :-) Having option (E) should make it easier to decide the best technical solution, separate from the promotion timing and where does it land question. We'll get back to you soon... Thanks! Dan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
Hi Dan, On Mon, Aug 06, 2012 at 09:21:22AM -0700, Dan Magenheimer wrote: From: Pekka Enberg [mailto:penb...@kernel.org] Subject: Re: [PATCH 0/4] promote zcache from staging On Mon, Aug 6, 2012 at 6:24 PM, Dan Magenheimer dan.magenhei...@oracle.com wrote: IMHO, the fastest way to get the best zcache into the kernel and to distros and users is to throw away the demo version, move forward to a new solid well-designed zcache code base, and work together to build on it. There's still a lot to do so I hope we can work together. I'm not convinced it's the _fastest way_. grin I guess I meant optimal, combining fast and best. You're effectively invalidating all the work done under drivers/staging so you might end up in review limbo with your shiny new code... Fixing the fundamental design flaws will sooner or later invalidate most (or all) of the previous testing/work anyway, won't it? Since any kernel built with staging is tainted already, I feel like now is a better time to make a major design transition. I suppose: (E) replace demo zcache with new code base and keep it in staging for another cycle I go for (E). Please send your refactoring code as formal patch. Thanks. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On Tue, Jul 31, 2012 at 11:36:04AM -0400, Konrad Rzeszutek Wilk wrote: > On Sun, Jul 29, 2012 at 10:54:28AM +0900, Minchan Kim wrote: > > On Fri, Jul 27, 2012 at 02:42:14PM -0700, Dan Magenheimer wrote: > > > > From: Konrad Rzeszutek Wilk [mailto:kon...@darnok.org] > > > > Sent: Friday, July 27, 2012 3:00 PM > > > > Subject: Re: [PATCH 0/4] promote zcache from staging > > > > > > > > On Fri, Jul 27, 2012 at 12:21:50PM -0700, Dan Magenheimer wrote: > > > > > > From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > > > > > > Subject: [PATCH 0/4] promote zcache from staging > > > > > > > > > > > > zcache is the remaining piece of code required to support in-kernel > > > > > > memory compression. The other two features, cleancache and > > > > > > frontswap, > > > > > > have been promoted to mainline in 3.0 and 3.5. This patchset > > > > > > promotes zcache from the staging tree to mainline. > > > > > > > > > > > > Based on the level of activity and contributions we're seeing from a > > > > > > diverse set of people and interests, I think zcache has matured to > > > > > > the > > > > > > point where it makes sense to promote this out of staging. > > > > > > > > > > Hi Seth -- > > > > > > > > > > Per offline communication, I'd like to see this delayed for three > > > > > reasons: > > > > > > > > > > 1) I've completely rewritten zcache and will post the rewrite soon. > > > > >The redesigned code fixes many of the weaknesses in zcache that > > > > >makes it (IMHO) unsuitable for an enterprise distro. (Some of > > > > >these previously discussed in linux-mm [1].) > > > > > 2) zcache is truly mm (memory management) code and the fact that > > > > >it is in drivers at all was purely for logistical reasons > > > > >(e.g. the only in-tree "staging" is in the drivers directory). > > > > >My rewrite promotes it to (a subdirectory of) mm where IMHO it > > > > >belongs. > > > > > 3) Ramster heavily duplicates code from zcache. My rewrite resolves > > > > >this. My soon-to-be-post also places the re-factored ramster > > > > >in mm, though with some minor work zcache could go in mm and > > > > >ramster could stay in staging. > > > > > > > > > > Let's have this discussion, but unless the community decides > > > > > otherwise, please consider this a NACK. > > > > > > Hi Konrad -- > > > > > > > Hold on, that is rather unfair. The zcache has been in staging > > > > for quite some time - your code has not been posted. Part of > > > > "unstaging" a driver is for folks to review the code - and you > > > > just said "No, mine is better" without showing your goods. > > > > > > Sorry, I'm not trying to be unfair. However, I don't see the point > > > of promoting zcache out of staging unless it is intended to be used > > > by real users in a real distro. There's been a lot of discussion, > > > onlist and offlist, about what needs to be fixed in zcache and not > > > much visible progress on fixing it. But fixing it is where I've spent > > > most of my time over the last couple of months. > > > > > > If IBM or some other company or distro is eager to ship and support > > > zcache in its current form, I agree that "promote now, improve later" > > > is a fine approach. But promoting zcache out of staging simply because > > > there is urgency to promote zsmalloc+zram out of staging doesn't > > > seem wise. At a minimum, it distracts reviewers/effort from what IMHO > > > is required to turn zcache into an enterprise-ready kernel feature. > > > > > > I can post my "goods" anytime. In its current form it is better > > > than the zcache in staging (and, please remember, I wrote both so > > > I think I am in a good position to compare the two). > > > I have been waiting until I think the new zcache is feature complete > > > before asking for review, especially since the newest features > > > should demonstrate clearly why the rewrite is necessary and > > > beneficial. But I can post* my current bits if people don't > > >
Re: [PATCH 0/4] promote zcache from staging
Hi Konrad, On Tue, Jul 31, 2012 at 01:51:42PM -0400, Konrad Rzeszutek Wilk wrote: > On Tue, Jul 31, 2012 at 09:19:16AM -0700, Greg Kroah-Hartman wrote: > > On Tue, Jul 31, 2012 at 11:58:43AM -0400, Konrad Rzeszutek Wilk wrote: > > > So in my head I feel that it is Ok to: > > > 1) address the concerns that zcache has before it is unstaged > > > 2) rip out the two-engine system with a one-engine system > > >(and see how well it behaves) > > > 3) sysfs->debugfs as needed > > > 4) other things as needed > > > > > > I think we are getting hung-up what Greg said about adding features > > > and the two-engine->one engine could be understood as that. > > > While I think that is part of a staging effort to clean up the > > > existing issues. Lets see what Greg thinks. > > > > Greg has no idea, except I want to see the needed fixups happen before > > new features get added. Add the new features _after_ it is out of > > staging. > > I think we (that is me, Seth, Minchan, Dan) need to talk to have a good > understanding of what each of us thinks are fixups. > > Would Monday Aug 6th at 1pm EST on irc.freenode.net channel #zcache work > for people? 1pm EST is 2am KST(Korea Standard Time) so it's not good for me. :) I know it's hard to adjust my time for yours so let you talk without me. Instead, I will write it down my requirement. It's very simple and trivial. 1) Please don't add any new feature like replace zsmalloc with zbud. It's totally untested so it needs more time for stable POV bug, or performance/fragementation. 2) Factor out common code between zcache and ramster. It should be just clean up code and should not change current behavior. 3) Add lots of comment to public functions 4) make function/varabiel names more clearly. They are necessary for promotion and after promotion, let's talk about new great features. > > > > > greg k-h > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
Hi Konrad, On Tue, Jul 31, 2012 at 01:51:42PM -0400, Konrad Rzeszutek Wilk wrote: On Tue, Jul 31, 2012 at 09:19:16AM -0700, Greg Kroah-Hartman wrote: On Tue, Jul 31, 2012 at 11:58:43AM -0400, Konrad Rzeszutek Wilk wrote: So in my head I feel that it is Ok to: 1) address the concerns that zcache has before it is unstaged 2) rip out the two-engine system with a one-engine system (and see how well it behaves) 3) sysfs-debugfs as needed 4) other things as needed I think we are getting hung-up what Greg said about adding features and the two-engine-one engine could be understood as that. While I think that is part of a staging effort to clean up the existing issues. Lets see what Greg thinks. Greg has no idea, except I want to see the needed fixups happen before new features get added. Add the new features _after_ it is out of staging. I think we (that is me, Seth, Minchan, Dan) need to talk to have a good understanding of what each of us thinks are fixups. Would Monday Aug 6th at 1pm EST on irc.freenode.net channel #zcache work for people? 1pm EST is 2am KST(Korea Standard Time) so it's not good for me. :) I know it's hard to adjust my time for yours so let you talk without me. Instead, I will write it down my requirement. It's very simple and trivial. 1) Please don't add any new feature like replace zsmalloc with zbud. It's totally untested so it needs more time for stable POV bug, or performance/fragementation. 2) Factor out common code between zcache and ramster. It should be just clean up code and should not change current behavior. 3) Add lots of comment to public functions 4) make function/varabiel names more clearly. They are necessary for promotion and after promotion, let's talk about new great features. greg k-h -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On Tue, Jul 31, 2012 at 11:36:04AM -0400, Konrad Rzeszutek Wilk wrote: On Sun, Jul 29, 2012 at 10:54:28AM +0900, Minchan Kim wrote: On Fri, Jul 27, 2012 at 02:42:14PM -0700, Dan Magenheimer wrote: From: Konrad Rzeszutek Wilk [mailto:kon...@darnok.org] Sent: Friday, July 27, 2012 3:00 PM Subject: Re: [PATCH 0/4] promote zcache from staging On Fri, Jul 27, 2012 at 12:21:50PM -0700, Dan Magenheimer wrote: From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] Subject: [PATCH 0/4] promote zcache from staging zcache is the remaining piece of code required to support in-kernel memory compression. The other two features, cleancache and frontswap, have been promoted to mainline in 3.0 and 3.5. This patchset promotes zcache from the staging tree to mainline. Based on the level of activity and contributions we're seeing from a diverse set of people and interests, I think zcache has matured to the point where it makes sense to promote this out of staging. Hi Seth -- Per offline communication, I'd like to see this delayed for three reasons: 1) I've completely rewritten zcache and will post the rewrite soon. The redesigned code fixes many of the weaknesses in zcache that makes it (IMHO) unsuitable for an enterprise distro. (Some of these previously discussed in linux-mm [1].) 2) zcache is truly mm (memory management) code and the fact that it is in drivers at all was purely for logistical reasons (e.g. the only in-tree staging is in the drivers directory). My rewrite promotes it to (a subdirectory of) mm where IMHO it belongs. 3) Ramster heavily duplicates code from zcache. My rewrite resolves this. My soon-to-be-post also places the re-factored ramster in mm, though with some minor work zcache could go in mm and ramster could stay in staging. Let's have this discussion, but unless the community decides otherwise, please consider this a NACK. Hi Konrad -- Hold on, that is rather unfair. The zcache has been in staging for quite some time - your code has not been posted. Part of unstaging a driver is for folks to review the code - and you just said No, mine is better without showing your goods. Sorry, I'm not trying to be unfair. However, I don't see the point of promoting zcache out of staging unless it is intended to be used by real users in a real distro. There's been a lot of discussion, onlist and offlist, about what needs to be fixed in zcache and not much visible progress on fixing it. But fixing it is where I've spent most of my time over the last couple of months. If IBM or some other company or distro is eager to ship and support zcache in its current form, I agree that promote now, improve later is a fine approach. But promoting zcache out of staging simply because there is urgency to promote zsmalloc+zram out of staging doesn't seem wise. At a minimum, it distracts reviewers/effort from what IMHO is required to turn zcache into an enterprise-ready kernel feature. I can post my goods anytime. In its current form it is better than the zcache in staging (and, please remember, I wrote both so I think I am in a good position to compare the two). I have been waiting until I think the new zcache is feature complete before asking for review, especially since the newest features should demonstrate clearly why the rewrite is necessary and beneficial. But I can post* my current bits if people don't believe they exist and/or don't mind reviewing non-final code. (* Or I can put them in a publicly available git tree.) There is a third option - which is to continue the promotion of zcache from staging, get reviews, work on them ,etc, and alongside of that you can work on fixing up (or ripping out) zcache1 with zcache2 components as they make sense. Or even having two of them - an enterprise and an embedded version that will eventually get merged together. There is nothing wrong with modifying a driver once it has left staging. Minchan and Seth can correct me if I am wrong, but I believe zram+zsmalloc, not zcache, is the target solution for embedded. NOT ture. Some embedded devices use zcache but it's not original zcache but modificated one. What kind of modifications? Would it make sense to post the patches It's for contiguos memory allocation. For it, it uses only clencache, not frontswap so it could zap ephemeral pages without latency for getting big contiguos memory. for those modifications? It's another story so at the moment, let's not consider it. After we got some cleanup, I will revisit it. Anyway, although embedded people use modified zcache, I am biased to Dan. I admit I don't spend lots of time
Re: [PATCH 0/4] promote zcache from staging
On 07/31/2012 12:51 PM, Konrad Rzeszutek Wilk wrote: > Would Monday Aug 6th at 1pm EST on irc.freenode.net channel #zcache work > for people? I think this is a great idea! Dan, can you post code as an RFC by tomorrow or Thursday? We (Rob and I) have the Texas Linux Fest starting Friday. We need time to review the code prior to chat so that we can talk about specifics rather than generalities. If that can be done, then we are available for the chat on Monday. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On Tue, Jul 31, 2012 at 09:19:16AM -0700, Greg Kroah-Hartman wrote: > On Tue, Jul 31, 2012 at 11:58:43AM -0400, Konrad Rzeszutek Wilk wrote: > > So in my head I feel that it is Ok to: > > 1) address the concerns that zcache has before it is unstaged > > 2) rip out the two-engine system with a one-engine system > >(and see how well it behaves) > > 3) sysfs->debugfs as needed > > 4) other things as needed > > > > I think we are getting hung-up what Greg said about adding features > > and the two-engine->one engine could be understood as that. > > While I think that is part of a staging effort to clean up the > > existing issues. Lets see what Greg thinks. > > Greg has no idea, except I want to see the needed fixups happen before > new features get added. Add the new features _after_ it is out of > staging. I think we (that is me, Seth, Minchan, Dan) need to talk to have a good understanding of what each of us thinks are fixups. Would Monday Aug 6th at 1pm EST on irc.freenode.net channel #zcache work for people? > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On Tue, Jul 31, 2012 at 11:58:43AM -0400, Konrad Rzeszutek Wilk wrote: > So in my head I feel that it is Ok to: > 1) address the concerns that zcache has before it is unstaged > 2) rip out the two-engine system with a one-engine system >(and see how well it behaves) > 3) sysfs->debugfs as needed > 4) other things as needed > > I think we are getting hung-up what Greg said about adding features > and the two-engine->one engine could be understood as that. > While I think that is part of a staging effort to clean up the > existing issues. Lets see what Greg thinks. Greg has no idea, except I want to see the needed fixups happen before new features get added. Add the new features _after_ it is out of staging. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On Mon, Jul 30, 2012 at 01:48:29PM -0700, Dan Magenheimer wrote: > > From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > > Subject: Re: [PATCH 0/4] promote zcache from staging > > > > Dan, > > > > I started writing inline responses to each concern but that > > was adding more confusion than clarity. I would like to > > focus the discussion. > > : > > Let's have this discussion. If there are specific issues > > that need to be addressed to get this ready for mainline > > let's take them one-by-one and line-by-line with patches. > > Hi Seth -- > > Thanks for your response and for your passion. > > The first discussion I think is about whether zsmalloc is > a suitable allocator for zcache. In its current state > in staging, zcache uses zbud for ephemeral (cleancache) > zpages and zsmalloc for persistent (frontswap) zpages. OK, but - unstaging 'zsmalloc' is a different patchset. > I have proposed concerns on-list that the capabilities > provided by zsmalloc are not suitable for supporting zcache > in an enterprise distro. The author of zsmalloc concurred The goal is to support _both_ enterprise and embedded. But what you are saying sounds like it does not work in enterprise environment - which is not my experience? If you are saying that the code should not be integrated before it works in both classes perfectly - well, then a lot of other code in the Linux should not have been accepted - and I would call those insufficienies "bugs". And bugs are .. natural, albeit pesky. I think what you are saing by "enterprise" is that you want it to be enabled by default (or at least be confident that it can be done so) for everybody and that it work quite well under 99% workload. While right now it covers only 98% (or some other number) of workload. > and has (at least so far) not been available to enhance > zsmalloc, and you have taken a strong position that zsmalloc > needed to be "generic" (i.e. will never deliver the functionality > IMHO is necessary for zcache). So I have rewritten zbud to > handle both kinds of zpages and, at the same time, to > resolve my stated issues. This is the bulk of my Ok, so zbud rewrite is to remove the need for zsmalloc and use zbud2 for both persistent and ephemeral pages. > major rewrite... I don't think constructing and reviewing > a long series of one-by-one and line-by-line patches is > of much value here, especially since the current code is > in staging. We either (1) use the now rewritten zbud (2) wait > until someone rewrites zsmalloc (3) accept the deficiencies > of zcache in its current form. This sounds like a Catch-22 :-) Greg would like to have the TODO list finished - and it seems that one of the todo's is to have one instead of two engines for dealing with pages. But at the same time not adding in new features. > > The second discussion is whether ramster, as a "user" of > zcache, is relevant. As you know, ramster is built on > top of zcache but requires a fair number of significant > changes that, due to gregkh's restriction, could not be > made directly to zcache while in staging. In my rewrite, > I've taken a great deal of care that the "new" zcache > cleanly supports both. While some couldn't care less about > ramster, the next step of ramster may be of more interest > to a broader part of the community. So I am eager to > ensure that the core zcache code in zcache and ramster > doesn't need to "fork" again. The zcache-main.c in staging/ramster > is farther along than the zcache-main.c in staging/zcache, but > IMHO my rewrite is better and cleaner than either. So in short you made zcache more modular? > > Most of the rest of the cleanup, such as converting to debugfs > instead of sysfs, could be done as a sequence of one-by-one > and line-by-line patches. I think we agree that zcache will Sure. Thought you could do it more wholesale: sysfs->debugfs patch. > not be promoted unless this change is made, but IMHO constructing > and reviewing patches individually is not of much value since > the above zbud and ramster changes already result in a major > rewrite. I think the community would benefit most from a new > solid code foundation for zcache and reviewers time (and your > time and mine) would best be spent grokking the new code than > from reviewing a very long sequence of cleanup patches. You are ignoring the goodness of the testing and performance numbers that zcache has gotten so far. With a new code those numbers are invalidated. That is throwing away some good data. Reviewing code based on the old code (and knowing how the old code works) I think is easier than trying to understand new code from scratch - at least one has a baseline to und
Re: [PATCH 0/4] promote zcache from staging
On Sun, Jul 29, 2012 at 10:54:28AM +0900, Minchan Kim wrote: > On Fri, Jul 27, 2012 at 02:42:14PM -0700, Dan Magenheimer wrote: > > > From: Konrad Rzeszutek Wilk [mailto:kon...@darnok.org] > > > Sent: Friday, July 27, 2012 3:00 PM > > > Subject: Re: [PATCH 0/4] promote zcache from staging > > > > > > On Fri, Jul 27, 2012 at 12:21:50PM -0700, Dan Magenheimer wrote: > > > > > From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > > > > > Subject: [PATCH 0/4] promote zcache from staging > > > > > > > > > > zcache is the remaining piece of code required to support in-kernel > > > > > memory compression. The other two features, cleancache and frontswap, > > > > > have been promoted to mainline in 3.0 and 3.5. This patchset > > > > > promotes zcache from the staging tree to mainline. > > > > > > > > > > Based on the level of activity and contributions we're seeing from a > > > > > diverse set of people and interests, I think zcache has matured to the > > > > > point where it makes sense to promote this out of staging. > > > > > > > > Hi Seth -- > > > > > > > > Per offline communication, I'd like to see this delayed for three > > > > reasons: > > > > > > > > 1) I've completely rewritten zcache and will post the rewrite soon. > > > >The redesigned code fixes many of the weaknesses in zcache that > > > >makes it (IMHO) unsuitable for an enterprise distro. (Some of > > > >these previously discussed in linux-mm [1].) > > > > 2) zcache is truly mm (memory management) code and the fact that > > > >it is in drivers at all was purely for logistical reasons > > > >(e.g. the only in-tree "staging" is in the drivers directory). > > > >My rewrite promotes it to (a subdirectory of) mm where IMHO it > > > >belongs. > > > > 3) Ramster heavily duplicates code from zcache. My rewrite resolves > > > >this. My soon-to-be-post also places the re-factored ramster > > > >in mm, though with some minor work zcache could go in mm and > > > >ramster could stay in staging. > > > > > > > > Let's have this discussion, but unless the community decides > > > > otherwise, please consider this a NACK. > > > > Hi Konrad -- > > > > > Hold on, that is rather unfair. The zcache has been in staging > > > for quite some time - your code has not been posted. Part of > > > "unstaging" a driver is for folks to review the code - and you > > > just said "No, mine is better" without showing your goods. > > > > Sorry, I'm not trying to be unfair. However, I don't see the point > > of promoting zcache out of staging unless it is intended to be used > > by real users in a real distro. There's been a lot of discussion, > > onlist and offlist, about what needs to be fixed in zcache and not > > much visible progress on fixing it. But fixing it is where I've spent > > most of my time over the last couple of months. > > > > If IBM or some other company or distro is eager to ship and support > > zcache in its current form, I agree that "promote now, improve later" > > is a fine approach. But promoting zcache out of staging simply because > > there is urgency to promote zsmalloc+zram out of staging doesn't > > seem wise. At a minimum, it distracts reviewers/effort from what IMHO > > is required to turn zcache into an enterprise-ready kernel feature. > > > > I can post my "goods" anytime. In its current form it is better > > than the zcache in staging (and, please remember, I wrote both so > > I think I am in a good position to compare the two). > > I have been waiting until I think the new zcache is feature complete > > before asking for review, especially since the newest features > > should demonstrate clearly why the rewrite is necessary and > > beneficial. But I can post* my current bits if people don't > > believe they exist and/or don't mind reviewing non-final code. > > (* Or I can put them in a publicly available git tree.) > > > > > There is a third option - which is to continue the promotion > > > of zcache from staging, get reviews, work on them ,etc, and > > > alongside of that you can work on fixing up (or ripping out) > > > zcache1 with zcache2 components as they make sense. Or even > > > having two of them - an enterprise and
Re: [PATCH 0/4] promote zcache from staging
On Sun, Jul 29, 2012 at 10:54:28AM +0900, Minchan Kim wrote: On Fri, Jul 27, 2012 at 02:42:14PM -0700, Dan Magenheimer wrote: From: Konrad Rzeszutek Wilk [mailto:kon...@darnok.org] Sent: Friday, July 27, 2012 3:00 PM Subject: Re: [PATCH 0/4] promote zcache from staging On Fri, Jul 27, 2012 at 12:21:50PM -0700, Dan Magenheimer wrote: From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] Subject: [PATCH 0/4] promote zcache from staging zcache is the remaining piece of code required to support in-kernel memory compression. The other two features, cleancache and frontswap, have been promoted to mainline in 3.0 and 3.5. This patchset promotes zcache from the staging tree to mainline. Based on the level of activity and contributions we're seeing from a diverse set of people and interests, I think zcache has matured to the point where it makes sense to promote this out of staging. Hi Seth -- Per offline communication, I'd like to see this delayed for three reasons: 1) I've completely rewritten zcache and will post the rewrite soon. The redesigned code fixes many of the weaknesses in zcache that makes it (IMHO) unsuitable for an enterprise distro. (Some of these previously discussed in linux-mm [1].) 2) zcache is truly mm (memory management) code and the fact that it is in drivers at all was purely for logistical reasons (e.g. the only in-tree staging is in the drivers directory). My rewrite promotes it to (a subdirectory of) mm where IMHO it belongs. 3) Ramster heavily duplicates code from zcache. My rewrite resolves this. My soon-to-be-post also places the re-factored ramster in mm, though with some minor work zcache could go in mm and ramster could stay in staging. Let's have this discussion, but unless the community decides otherwise, please consider this a NACK. Hi Konrad -- Hold on, that is rather unfair. The zcache has been in staging for quite some time - your code has not been posted. Part of unstaging a driver is for folks to review the code - and you just said No, mine is better without showing your goods. Sorry, I'm not trying to be unfair. However, I don't see the point of promoting zcache out of staging unless it is intended to be used by real users in a real distro. There's been a lot of discussion, onlist and offlist, about what needs to be fixed in zcache and not much visible progress on fixing it. But fixing it is where I've spent most of my time over the last couple of months. If IBM or some other company or distro is eager to ship and support zcache in its current form, I agree that promote now, improve later is a fine approach. But promoting zcache out of staging simply because there is urgency to promote zsmalloc+zram out of staging doesn't seem wise. At a minimum, it distracts reviewers/effort from what IMHO is required to turn zcache into an enterprise-ready kernel feature. I can post my goods anytime. In its current form it is better than the zcache in staging (and, please remember, I wrote both so I think I am in a good position to compare the two). I have been waiting until I think the new zcache is feature complete before asking for review, especially since the newest features should demonstrate clearly why the rewrite is necessary and beneficial. But I can post* my current bits if people don't believe they exist and/or don't mind reviewing non-final code. (* Or I can put them in a publicly available git tree.) There is a third option - which is to continue the promotion of zcache from staging, get reviews, work on them ,etc, and alongside of that you can work on fixing up (or ripping out) zcache1 with zcache2 components as they make sense. Or even having two of them - an enterprise and an embedded version that will eventually get merged together. There is nothing wrong with modifying a driver once it has left staging. Minchan and Seth can correct me if I am wrong, but I believe zram+zsmalloc, not zcache, is the target solution for embedded. NOT ture. Some embedded devices use zcache but it's not original zcache but modificated one. What kind of modifications? Would it make sense to post the patches for those modifications? Anyway, although embedded people use modified zcache, I am biased to Dan. I admit I don't spend lots of time to look zcache but as looking the code, it wasn't good shape and even had a bug found during code review and I felt strongly we should clean up it for promoting it to mm/. Do you recall what the bugs where? So I would like to wait Dan's posting if you guys are not urgent. (And I am not sure akpm allow it with current shape of zcache code.) But the concern is about adding new feature. I guess there might be some debate for long time
Re: [PATCH 0/4] promote zcache from staging
On Mon, Jul 30, 2012 at 01:48:29PM -0700, Dan Magenheimer wrote: From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] Subject: Re: [PATCH 0/4] promote zcache from staging Dan, I started writing inline responses to each concern but that was adding more confusion than clarity. I would like to focus the discussion. : Let's have this discussion. If there are specific issues that need to be addressed to get this ready for mainline let's take them one-by-one and line-by-line with patches. Hi Seth -- Thanks for your response and for your passion. The first discussion I think is about whether zsmalloc is a suitable allocator for zcache. In its current state in staging, zcache uses zbud for ephemeral (cleancache) zpages and zsmalloc for persistent (frontswap) zpages. OK, but - unstaging 'zsmalloc' is a different patchset. I have proposed concerns on-list that the capabilities provided by zsmalloc are not suitable for supporting zcache in an enterprise distro. The author of zsmalloc concurred The goal is to support _both_ enterprise and embedded. But what you are saying sounds like it does not work in enterprise environment - which is not my experience? If you are saying that the code should not be integrated before it works in both classes perfectly - well, then a lot of other code in the Linux should not have been accepted - and I would call those insufficienies bugs. And bugs are .. natural, albeit pesky. I think what you are saing by enterprise is that you want it to be enabled by default (or at least be confident that it can be done so) for everybody and that it work quite well under 99% workload. While right now it covers only 98% (or some other number) of workload. and has (at least so far) not been available to enhance zsmalloc, and you have taken a strong position that zsmalloc needed to be generic (i.e. will never deliver the functionality IMHO is necessary for zcache). So I have rewritten zbud to handle both kinds of zpages and, at the same time, to resolve my stated issues. This is the bulk of my Ok, so zbud rewrite is to remove the need for zsmalloc and use zbud2 for both persistent and ephemeral pages. major rewrite... I don't think constructing and reviewing a long series of one-by-one and line-by-line patches is of much value here, especially since the current code is in staging. We either (1) use the now rewritten zbud (2) wait until someone rewrites zsmalloc (3) accept the deficiencies of zcache in its current form. This sounds like a Catch-22 :-) Greg would like to have the TODO list finished - and it seems that one of the todo's is to have one instead of two engines for dealing with pages. But at the same time not adding in new features. The second discussion is whether ramster, as a user of zcache, is relevant. As you know, ramster is built on top of zcache but requires a fair number of significant changes that, due to gregkh's restriction, could not be made directly to zcache while in staging. In my rewrite, I've taken a great deal of care that the new zcache cleanly supports both. While some couldn't care less about ramster, the next step of ramster may be of more interest to a broader part of the community. So I am eager to ensure that the core zcache code in zcache and ramster doesn't need to fork again. The zcache-main.c in staging/ramster is farther along than the zcache-main.c in staging/zcache, but IMHO my rewrite is better and cleaner than either. So in short you made zcache more modular? Most of the rest of the cleanup, such as converting to debugfs instead of sysfs, could be done as a sequence of one-by-one and line-by-line patches. I think we agree that zcache will Sure. Thought you could do it more wholesale: sysfs-debugfs patch. not be promoted unless this change is made, but IMHO constructing and reviewing patches individually is not of much value since the above zbud and ramster changes already result in a major rewrite. I think the community would benefit most from a new solid code foundation for zcache and reviewers time (and your time and mine) would best be spent grokking the new code than from reviewing a very long sequence of cleanup patches. You are ignoring the goodness of the testing and performance numbers that zcache has gotten so far. With a new code those numbers are invalidated. That is throwing away some good data. Reviewing code based on the old code (and knowing how the old code works) I think is easier than trying to understand new code from scratch - at least one has a baseline to undertand it. But that might be just my opinion - either way I am OK looking at brand new code or old code - but I would end up looking at the old code to answer those : Huh. I wonder how we did that previously. - at which point it might make sense just to have the patches broken up in small segments. The purpose of this patchset is to discuss the inclusion
Re: [PATCH 0/4] promote zcache from staging
On Tue, Jul 31, 2012 at 11:58:43AM -0400, Konrad Rzeszutek Wilk wrote: So in my head I feel that it is Ok to: 1) address the concerns that zcache has before it is unstaged 2) rip out the two-engine system with a one-engine system (and see how well it behaves) 3) sysfs-debugfs as needed 4) other things as needed I think we are getting hung-up what Greg said about adding features and the two-engine-one engine could be understood as that. While I think that is part of a staging effort to clean up the existing issues. Lets see what Greg thinks. Greg has no idea, except I want to see the needed fixups happen before new features get added. Add the new features _after_ it is out of staging. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On Tue, Jul 31, 2012 at 09:19:16AM -0700, Greg Kroah-Hartman wrote: On Tue, Jul 31, 2012 at 11:58:43AM -0400, Konrad Rzeszutek Wilk wrote: So in my head I feel that it is Ok to: 1) address the concerns that zcache has before it is unstaged 2) rip out the two-engine system with a one-engine system (and see how well it behaves) 3) sysfs-debugfs as needed 4) other things as needed I think we are getting hung-up what Greg said about adding features and the two-engine-one engine could be understood as that. While I think that is part of a staging effort to clean up the existing issues. Lets see what Greg thinks. Greg has no idea, except I want to see the needed fixups happen before new features get added. Add the new features _after_ it is out of staging. I think we (that is me, Seth, Minchan, Dan) need to talk to have a good understanding of what each of us thinks are fixups. Would Monday Aug 6th at 1pm EST on irc.freenode.net channel #zcache work for people? greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On 07/31/2012 12:51 PM, Konrad Rzeszutek Wilk wrote: Would Monday Aug 6th at 1pm EST on irc.freenode.net channel #zcache work for people? I think this is a great idea! Dan, can you post code as an RFC by tomorrow or Thursday? We (Rob and I) have the Texas Linux Fest starting Friday. We need time to review the code prior to chat so that we can talk about specifics rather than generalities. If that can be done, then we are available for the chat on Monday. Seth -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > Subject: Re: [PATCH 0/4] promote zcache from staging > > Dan, > > I started writing inline responses to each concern but that > was adding more confusion than clarity. I would like to > focus the discussion. > : > Let's have this discussion. If there are specific issues > that need to be addressed to get this ready for mainline > let's take them one-by-one and line-by-line with patches. Hi Seth -- Thanks for your response and for your passion. The first discussion I think is about whether zsmalloc is a suitable allocator for zcache. In its current state in staging, zcache uses zbud for ephemeral (cleancache) zpages and zsmalloc for persistent (frontswap) zpages. I have proposed concerns on-list that the capabilities provided by zsmalloc are not suitable for supporting zcache in an enterprise distro. The author of zsmalloc concurred and has (at least so far) not been available to enhance zsmalloc, and you have taken a strong position that zsmalloc needed to be "generic" (i.e. will never deliver the functionality IMHO is necessary for zcache). So I have rewritten zbud to handle both kinds of zpages and, at the same time, to resolve my stated issues. This is the bulk of my major rewrite... I don't think constructing and reviewing a long series of one-by-one and line-by-line patches is of much value here, especially since the current code is in staging. We either (1) use the now rewritten zbud (2) wait until someone rewrites zsmalloc (3) accept the deficiencies of zcache in its current form. The second discussion is whether ramster, as a "user" of zcache, is relevant. As you know, ramster is built on top of zcache but requires a fair number of significant changes that, due to gregkh's restriction, could not be made directly to zcache while in staging. In my rewrite, I've taken a great deal of care that the "new" zcache cleanly supports both. While some couldn't care less about ramster, the next step of ramster may be of more interest to a broader part of the community. So I am eager to ensure that the core zcache code in zcache and ramster doesn't need to "fork" again. The zcache-main.c in staging/ramster is farther along than the zcache-main.c in staging/zcache, but IMHO my rewrite is better and cleaner than either. Most of the rest of the cleanup, such as converting to debugfs instead of sysfs, could be done as a sequence of one-by-one and line-by-line patches. I think we agree that zcache will not be promoted unless this change is made, but IMHO constructing and reviewing patches individually is not of much value since the above zbud and ramster changes already result in a major rewrite. I think the community would benefit most from a new solid code foundation for zcache and reviewers time (and your time and mine) would best be spent grokking the new code than from reviewing a very long sequence of cleanup patches. > The purpose of this patchset is to discuss the inclusion of > zcache into mainline during the 3.7 merge window. zcache > has been a staging since v2.6.39 and has been maturing with > contributions from 15 developers (5 with multiple commits) > working on improvements and bug fixes. > > I want good code in the kernel, so if there are particular > areas that need attention before it's of acceptable quality > for mainline we need that discussion. I am eager to have > customers using memory compression with zcache but before > that I want to see zcache in mainline. I think we are all eager to achieve the end result: real users using zcache in real production systems. IMHO your suggested path will not achieve that, certainly not in the 3.7 timeframe. The current code (IMHO) is neither suitable for promotion, nor functionally capable of taking the beating of an enterprise distro. > We agree with Konrad that zcache should be promoted before > additional features are included. Greg has also expressed > that he would like promotion before attempting to add > additional features [1]. Including new features now, while > in the staging tree, adds to the complexity and difficultly > of reverifying zcache and getting it accepted into mainline. > > [1] https://lkml.org/lkml/2012/3/16/472still in staging. Zcache as submitted to staging in 2.6.39 was (and is) a working proof-of-concept. As you know, Greg's position created a "catch 22"... zcache in its current state isn't good enough to be promoted, but we can't change it substantially to resolve its deficiencies while it is still in staging. (Minchan recently stated that he doesn't think it is in good enough shape to be approved by Andrew, and I agree.) That's why I embarked on the rewrite. Lastly, I'm not so much "adding new features" as ensuring the new zcache foundation will be sufficient to support enterp
Re: [PATCH 0/4] promote zcache from staging
Dan, I started writing inline responses to each concern but that was adding more confusion than clarity. I would like to focus the discussion. The purpose of this patchset is to discuss the inclusion of zcache into mainline during the 3.7 merge window. zcache has been a staging since v2.6.39 and has been maturing with contributions from 15 developers (5 with multiple commits) working on improvements and bug fixes. I want good code in the kernel, so if there are particular areas that need attention before it's of acceptable quality for mainline we need that discussion. I am eager to have customers using memory compression with zcache but before that I want to see zcache in mainline. We agree with Konrad that zcache should be promoted before additional features are included. Greg has also expressed that he would like promotion before attempting to add additional features [1]. Including new features now, while in the staging tree, adds to the complexity and difficultly of reverifying zcache and getting it accepted into mainline. [1] https://lkml.org/lkml/2012/3/16/472 Let's have this discussion. If there are specific issues that need to be addressed to get this ready for mainline let's take them one-by-one and line-by-line with patches. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
Dan, I started writing inline responses to each concern but that was adding more confusion than clarity. I would like to focus the discussion. The purpose of this patchset is to discuss the inclusion of zcache into mainline during the 3.7 merge window. zcache has been a staging since v2.6.39 and has been maturing with contributions from 15 developers (5 with multiple commits) working on improvements and bug fixes. I want good code in the kernel, so if there are particular areas that need attention before it's of acceptable quality for mainline we need that discussion. I am eager to have customers using memory compression with zcache but before that I want to see zcache in mainline. We agree with Konrad that zcache should be promoted before additional features are included. Greg has also expressed that he would like promotion before attempting to add additional features [1]. Including new features now, while in the staging tree, adds to the complexity and difficultly of reverifying zcache and getting it accepted into mainline. [1] https://lkml.org/lkml/2012/3/16/472 Let's have this discussion. If there are specific issues that need to be addressed to get this ready for mainline let's take them one-by-one and line-by-line with patches. Seth -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] Subject: Re: [PATCH 0/4] promote zcache from staging Dan, I started writing inline responses to each concern but that was adding more confusion than clarity. I would like to focus the discussion. : Let's have this discussion. If there are specific issues that need to be addressed to get this ready for mainline let's take them one-by-one and line-by-line with patches. Hi Seth -- Thanks for your response and for your passion. The first discussion I think is about whether zsmalloc is a suitable allocator for zcache. In its current state in staging, zcache uses zbud for ephemeral (cleancache) zpages and zsmalloc for persistent (frontswap) zpages. I have proposed concerns on-list that the capabilities provided by zsmalloc are not suitable for supporting zcache in an enterprise distro. The author of zsmalloc concurred and has (at least so far) not been available to enhance zsmalloc, and you have taken a strong position that zsmalloc needed to be generic (i.e. will never deliver the functionality IMHO is necessary for zcache). So I have rewritten zbud to handle both kinds of zpages and, at the same time, to resolve my stated issues. This is the bulk of my major rewrite... I don't think constructing and reviewing a long series of one-by-one and line-by-line patches is of much value here, especially since the current code is in staging. We either (1) use the now rewritten zbud (2) wait until someone rewrites zsmalloc (3) accept the deficiencies of zcache in its current form. The second discussion is whether ramster, as a user of zcache, is relevant. As you know, ramster is built on top of zcache but requires a fair number of significant changes that, due to gregkh's restriction, could not be made directly to zcache while in staging. In my rewrite, I've taken a great deal of care that the new zcache cleanly supports both. While some couldn't care less about ramster, the next step of ramster may be of more interest to a broader part of the community. So I am eager to ensure that the core zcache code in zcache and ramster doesn't need to fork again. The zcache-main.c in staging/ramster is farther along than the zcache-main.c in staging/zcache, but IMHO my rewrite is better and cleaner than either. Most of the rest of the cleanup, such as converting to debugfs instead of sysfs, could be done as a sequence of one-by-one and line-by-line patches. I think we agree that zcache will not be promoted unless this change is made, but IMHO constructing and reviewing patches individually is not of much value since the above zbud and ramster changes already result in a major rewrite. I think the community would benefit most from a new solid code foundation for zcache and reviewers time (and your time and mine) would best be spent grokking the new code than from reviewing a very long sequence of cleanup patches. The purpose of this patchset is to discuss the inclusion of zcache into mainline during the 3.7 merge window. zcache has been a staging since v2.6.39 and has been maturing with contributions from 15 developers (5 with multiple commits) working on improvements and bug fixes. I want good code in the kernel, so if there are particular areas that need attention before it's of acceptable quality for mainline we need that discussion. I am eager to have customers using memory compression with zcache but before that I want to see zcache in mainline. I think we are all eager to achieve the end result: real users using zcache in real production systems. IMHO your suggested path will not achieve that, certainly not in the 3.7 timeframe. The current code (IMHO) is neither suitable for promotion, nor functionally capable of taking the beating of an enterprise distro. We agree with Konrad that zcache should be promoted before additional features are included. Greg has also expressed that he would like promotion before attempting to add additional features [1]. Including new features now, while in the staging tree, adds to the complexity and difficultly of reverifying zcache and getting it accepted into mainline. [1] https://lkml.org/lkml/2012/3/16/472still in staging. Zcache as submitted to staging in 2.6.39 was (and is) a working proof-of-concept. As you know, Greg's position created a catch 22... zcache in its current state isn't good enough to be promoted, but we can't change it substantially to resolve its deficiencies while it is still in staging. (Minchan recently stated that he doesn't think it is in good enough shape to be approved by Andrew, and I agree.) That's why I embarked on the rewrite. Lastly, I'm not so much adding new features as ensuring the new zcache foundation will be sufficient to support enterprise users. But I do now agree with Minchan (and I think with you) that I need to post where I'm at, even if I am not 100% ready or satisfied. I'll try to do that by the end of the week. Thanks
Re: [PATCH 0/4] promote zcache from staging
Hi Seth,
zcache out of staging is rather controversial as you see this thread.
But I believe zram is very mature and code/comment is clean. In addition,
it has lots of real customers in embedded side so IMHO, it would be easy to
promote it firstly. Of course, it will promote zsmalloc which is half on
what you want. What do you think about? If you agree, could you do that firstly?
If you don't want and promoting zcache continue to be controversial,
I will do that after my vacation.
Thanks.
On Fri, Jul 27, 2012 at 01:18:33PM -0500, Seth Jennings wrote:
> zcache is the remaining piece of code required to support in-kernel
> memory compression. The other two features, cleancache and frontswap,
> have been promoted to mainline in 3.0 and 3.5. This patchset
> promotes zcache from the staging tree to mainline.
>
> Based on the level of activity and contributions we're seeing from a
> diverse set of people and interests, I think zcache has matured to the
> point where it makes sense to promote this out of staging.
>
> Overview
>
> zcache is a backend to frontswap and cleancache that accepts pages from
> those mechanisms and compresses them, leading to reduced I/O caused by
> swap and file re-reads. This is very valuable in shared storage situations
> to reduce load on things like SANs. Also, in the case of slow backing/swap
> devices, zcache can also yield a performance gain.
>
> In-Kernel Memory Compression Overview:
>
> swap subsystempage cache
> + +
> frontswap cleancache
> + +
> zcache frontswap glue zcache cleancache glue
> + +
> +-++
> +
> zcache/tmem core
> +
> +-++
> + +
> zsmalloc zbud
>
> Everything below the frontswap/cleancache layer is current inside the
> zcache driver expect for zsmalloc which is a shared between zcache and
> another memory compression driver, zram.
>
> Since zcache is dependent on zsmalloc, it is also being promoted by this
> patchset.
>
> For information on zsmalloc and the rationale behind it's design and use
> cases verses already existing allocators in the kernel:
>
> https://lkml.org/lkml/2012/1/9/386
>
> zsmalloc is the allocator used by zcache to store persistent pages that
> comes from frontswap, as opposed to zbud which is the (internal) allocator
> used for ephemeral pages from cleancache.
>
> zsmalloc uses many fields of the page struct to create it's conceptual
> high-order page called a zspage. Exactly which fields are used and for
> what purpose is documented at the top of the zsmalloc .c file. Because
> zsmalloc uses struct page extensively, Andrew advised that the
> promotion location be mm/:
>
> https://lkml.org/lkml/2012/1/20/308
>
> Some benchmarking numbers demonstrating the I/O saving that can be had
> with zcache:
>
> https://lkml.org/lkml/2012/3/22/383
>
> Dan's presentation at LSF/MM this year on zcache:
>
> http://oss.oracle.com/projects/tmem/dist/documentation/presentations/LSFMM12-zcache-final.pdf
>
> This patchset is based on next-20120727 + 3-part zsmalloc patchset below
>
> https://lkml.org/lkml/2012/7/18/353
>
> The zsmalloc patchset is already acked and will be integrated by Greg after
> 3.6-rc1 is out.
>
> Seth Jennings (4):
> zsmalloc: collapse internal .h into .c
> zsmalloc: promote to mm/
> drivers: add memory management driver class
> zcache: promote to drivers/mm/
>
> drivers/Kconfig|2 +
> drivers/Makefile |1 +
> drivers/mm/Kconfig | 13 ++
> drivers/mm/Makefile|1 +
> drivers/{staging => mm}/zcache/Makefile|0
> drivers/{staging => mm}/zcache/tmem.c |0
> drivers/{staging => mm}/zcache/tmem.h |0
> drivers/{staging => mm}/zcache/zcache-main.c |4 +-
> drivers/staging/Kconfig|4 -
> drivers/staging/Makefile |2 -
> drivers/staging/zcache/Kconfig | 11 --
> drivers/staging/zram/zram_drv.h|3 +-
> drivers/staging/zsmalloc/Kconfig | 10 --
> drivers/staging/zsmalloc/Makefile |3 -
> drivers/staging/zsmalloc/zsmalloc_int.h| 149
>
> .../staging/zsmalloc => include/linux}/zsmalloc.h |0
> mm/Kconfig | 18 +++
> mm/Makefile|1 +
> .../zsmalloc/zsmalloc-main.c => mm/zsmalloc.c | 133 -
> 19 files changed, 170 insertions(+), 185 deletions(-)
> create mode 100644 drivers/mm/Kconfig
> create mode 100644 drivers/mm/Makefile
> rename
Re: [PATCH 0/4] promote zcache from staging
On Fri, Jul 27, 2012 at 02:42:14PM -0700, Dan Magenheimer wrote: > > From: Konrad Rzeszutek Wilk [mailto:kon...@darnok.org] > > Sent: Friday, July 27, 2012 3:00 PM > > Subject: Re: [PATCH 0/4] promote zcache from staging > > > > On Fri, Jul 27, 2012 at 12:21:50PM -0700, Dan Magenheimer wrote: > > > > From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > > > > Subject: [PATCH 0/4] promote zcache from staging > > > > > > > > zcache is the remaining piece of code required to support in-kernel > > > > memory compression. The other two features, cleancache and frontswap, > > > > have been promoted to mainline in 3.0 and 3.5. This patchset > > > > promotes zcache from the staging tree to mainline. > > > > > > > > Based on the level of activity and contributions we're seeing from a > > > > diverse set of people and interests, I think zcache has matured to the > > > > point where it makes sense to promote this out of staging. > > > > > > Hi Seth -- > > > > > > Per offline communication, I'd like to see this delayed for three > > > reasons: > > > > > > 1) I've completely rewritten zcache and will post the rewrite soon. > > >The redesigned code fixes many of the weaknesses in zcache that > > >makes it (IMHO) unsuitable for an enterprise distro. (Some of > > >these previously discussed in linux-mm [1].) > > > 2) zcache is truly mm (memory management) code and the fact that > > >it is in drivers at all was purely for logistical reasons > > >(e.g. the only in-tree "staging" is in the drivers directory). > > >My rewrite promotes it to (a subdirectory of) mm where IMHO it > > >belongs. > > > 3) Ramster heavily duplicates code from zcache. My rewrite resolves > > >this. My soon-to-be-post also places the re-factored ramster > > >in mm, though with some minor work zcache could go in mm and > > >ramster could stay in staging. > > > > > > Let's have this discussion, but unless the community decides > > > otherwise, please consider this a NACK. > > Hi Konrad -- > > > Hold on, that is rather unfair. The zcache has been in staging > > for quite some time - your code has not been posted. Part of > > "unstaging" a driver is for folks to review the code - and you > > just said "No, mine is better" without showing your goods. > > Sorry, I'm not trying to be unfair. However, I don't see the point > of promoting zcache out of staging unless it is intended to be used > by real users in a real distro. There's been a lot of discussion, > onlist and offlist, about what needs to be fixed in zcache and not > much visible progress on fixing it. But fixing it is where I've spent > most of my time over the last couple of months. > > If IBM or some other company or distro is eager to ship and support > zcache in its current form, I agree that "promote now, improve later" > is a fine approach. But promoting zcache out of staging simply because > there is urgency to promote zsmalloc+zram out of staging doesn't > seem wise. At a minimum, it distracts reviewers/effort from what IMHO > is required to turn zcache into an enterprise-ready kernel feature. > > I can post my "goods" anytime. In its current form it is better > than the zcache in staging (and, please remember, I wrote both so > I think I am in a good position to compare the two). > I have been waiting until I think the new zcache is feature complete > before asking for review, especially since the newest features > should demonstrate clearly why the rewrite is necessary and > beneficial. But I can post* my current bits if people don't > believe they exist and/or don't mind reviewing non-final code. > (* Or I can put them in a publicly available git tree.) > > > There is a third option - which is to continue the promotion > > of zcache from staging, get reviews, work on them ,etc, and > > alongside of that you can work on fixing up (or ripping out) > > zcache1 with zcache2 components as they make sense. Or even > > having two of them - an enterprise and an embedded version > > that will eventually get merged together. There is nothing > > wrong with modifying a driver once it has left staging. > > Minchan and Seth can correct me if I am wrong, but I believe > zram+zsmalloc, not zcache, is the target solution for embedded. NOT ture. Some embedded devices use zcache but it's not original zcache but modificated one. Anyway, although embedded people use modified zc
Re: [PATCH 0/4] promote zcache from staging
On Fri, Jul 27, 2012 at 02:42:14PM -0700, Dan Magenheimer wrote: From: Konrad Rzeszutek Wilk [mailto:kon...@darnok.org] Sent: Friday, July 27, 2012 3:00 PM Subject: Re: [PATCH 0/4] promote zcache from staging On Fri, Jul 27, 2012 at 12:21:50PM -0700, Dan Magenheimer wrote: From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] Subject: [PATCH 0/4] promote zcache from staging zcache is the remaining piece of code required to support in-kernel memory compression. The other two features, cleancache and frontswap, have been promoted to mainline in 3.0 and 3.5. This patchset promotes zcache from the staging tree to mainline. Based on the level of activity and contributions we're seeing from a diverse set of people and interests, I think zcache has matured to the point where it makes sense to promote this out of staging. Hi Seth -- Per offline communication, I'd like to see this delayed for three reasons: 1) I've completely rewritten zcache and will post the rewrite soon. The redesigned code fixes many of the weaknesses in zcache that makes it (IMHO) unsuitable for an enterprise distro. (Some of these previously discussed in linux-mm [1].) 2) zcache is truly mm (memory management) code and the fact that it is in drivers at all was purely for logistical reasons (e.g. the only in-tree staging is in the drivers directory). My rewrite promotes it to (a subdirectory of) mm where IMHO it belongs. 3) Ramster heavily duplicates code from zcache. My rewrite resolves this. My soon-to-be-post also places the re-factored ramster in mm, though with some minor work zcache could go in mm and ramster could stay in staging. Let's have this discussion, but unless the community decides otherwise, please consider this a NACK. Hi Konrad -- Hold on, that is rather unfair. The zcache has been in staging for quite some time - your code has not been posted. Part of unstaging a driver is for folks to review the code - and you just said No, mine is better without showing your goods. Sorry, I'm not trying to be unfair. However, I don't see the point of promoting zcache out of staging unless it is intended to be used by real users in a real distro. There's been a lot of discussion, onlist and offlist, about what needs to be fixed in zcache and not much visible progress on fixing it. But fixing it is where I've spent most of my time over the last couple of months. If IBM or some other company or distro is eager to ship and support zcache in its current form, I agree that promote now, improve later is a fine approach. But promoting zcache out of staging simply because there is urgency to promote zsmalloc+zram out of staging doesn't seem wise. At a minimum, it distracts reviewers/effort from what IMHO is required to turn zcache into an enterprise-ready kernel feature. I can post my goods anytime. In its current form it is better than the zcache in staging (and, please remember, I wrote both so I think I am in a good position to compare the two). I have been waiting until I think the new zcache is feature complete before asking for review, especially since the newest features should demonstrate clearly why the rewrite is necessary and beneficial. But I can post* my current bits if people don't believe they exist and/or don't mind reviewing non-final code. (* Or I can put them in a publicly available git tree.) There is a third option - which is to continue the promotion of zcache from staging, get reviews, work on them ,etc, and alongside of that you can work on fixing up (or ripping out) zcache1 with zcache2 components as they make sense. Or even having two of them - an enterprise and an embedded version that will eventually get merged together. There is nothing wrong with modifying a driver once it has left staging. Minchan and Seth can correct me if I am wrong, but I believe zram+zsmalloc, not zcache, is the target solution for embedded. NOT ture. Some embedded devices use zcache but it's not original zcache but modificated one. Anyway, although embedded people use modified zcache, I am biased to Dan. I admit I don't spend lots of time to look zcache but as looking the code, it wasn't good shape and even had a bug found during code review and I felt strongly we should clean up it for promoting it to mm/. So I would like to wait Dan's posting if you guys are not urgent. (And I am not sure akpm allow it with current shape of zcache code.) But the concern is about adding new feature. I guess there might be some debate for long time and it can prevent promoting again. I think It's not what Seth want. I hope Dan doesn't mix clean up series and new feature series and post clean up series as soon as possible so let's clean up first and try to promote it and later, adding new feature or changing algorithm is desirable
Re: [PATCH 0/4] promote zcache from staging
Hi Seth,
zcache out of staging is rather controversial as you see this thread.
But I believe zram is very mature and code/comment is clean. In addition,
it has lots of real customers in embedded side so IMHO, it would be easy to
promote it firstly. Of course, it will promote zsmalloc which is half on
what you want. What do you think about? If you agree, could you do that firstly?
If you don't want and promoting zcache continue to be controversial,
I will do that after my vacation.
Thanks.
On Fri, Jul 27, 2012 at 01:18:33PM -0500, Seth Jennings wrote:
zcache is the remaining piece of code required to support in-kernel
memory compression. The other two features, cleancache and frontswap,
have been promoted to mainline in 3.0 and 3.5. This patchset
promotes zcache from the staging tree to mainline.
Based on the level of activity and contributions we're seeing from a
diverse set of people and interests, I think zcache has matured to the
point where it makes sense to promote this out of staging.
Overview
zcache is a backend to frontswap and cleancache that accepts pages from
those mechanisms and compresses them, leading to reduced I/O caused by
swap and file re-reads. This is very valuable in shared storage situations
to reduce load on things like SANs. Also, in the case of slow backing/swap
devices, zcache can also yield a performance gain.
In-Kernel Memory Compression Overview:
swap subsystempage cache
+ +
frontswap cleancache
+ +
zcache frontswap glue zcache cleancache glue
+ +
+-++
+
zcache/tmem core
+
+-++
+ +
zsmalloc zbud
Everything below the frontswap/cleancache layer is current inside the
zcache driver expect for zsmalloc which is a shared between zcache and
another memory compression driver, zram.
Since zcache is dependent on zsmalloc, it is also being promoted by this
patchset.
For information on zsmalloc and the rationale behind it's design and use
cases verses already existing allocators in the kernel:
https://lkml.org/lkml/2012/1/9/386
zsmalloc is the allocator used by zcache to store persistent pages that
comes from frontswap, as opposed to zbud which is the (internal) allocator
used for ephemeral pages from cleancache.
zsmalloc uses many fields of the page struct to create it's conceptual
high-order page called a zspage. Exactly which fields are used and for
what purpose is documented at the top of the zsmalloc .c file. Because
zsmalloc uses struct page extensively, Andrew advised that the
promotion location be mm/:
https://lkml.org/lkml/2012/1/20/308
Some benchmarking numbers demonstrating the I/O saving that can be had
with zcache:
https://lkml.org/lkml/2012/3/22/383
Dan's presentation at LSF/MM this year on zcache:
http://oss.oracle.com/projects/tmem/dist/documentation/presentations/LSFMM12-zcache-final.pdf
This patchset is based on next-20120727 + 3-part zsmalloc patchset below
https://lkml.org/lkml/2012/7/18/353
The zsmalloc patchset is already acked and will be integrated by Greg after
3.6-rc1 is out.
Seth Jennings (4):
zsmalloc: collapse internal .h into .c
zsmalloc: promote to mm/
drivers: add memory management driver class
zcache: promote to drivers/mm/
drivers/Kconfig|2 +
drivers/Makefile |1 +
drivers/mm/Kconfig | 13 ++
drivers/mm/Makefile|1 +
drivers/{staging = mm}/zcache/Makefile|0
drivers/{staging = mm}/zcache/tmem.c |0
drivers/{staging = mm}/zcache/tmem.h |0
drivers/{staging = mm}/zcache/zcache-main.c |4 +-
drivers/staging/Kconfig|4 -
drivers/staging/Makefile |2 -
drivers/staging/zcache/Kconfig | 11 --
drivers/staging/zram/zram_drv.h|3 +-
drivers/staging/zsmalloc/Kconfig | 10 --
drivers/staging/zsmalloc/Makefile |3 -
drivers/staging/zsmalloc/zsmalloc_int.h| 149
.../staging/zsmalloc = include/linux}/zsmalloc.h |0
mm/Kconfig | 18 +++
mm/Makefile|1 +
.../zsmalloc/zsmalloc-main.c = mm/zsmalloc.c | 133 -
19 files changed, 170 insertions(+), 185 deletions(-)
create mode 100644 drivers/mm/Kconfig
create mode 100644 drivers/mm/Makefile
rename drivers/{staging = mm}/zcache/Makefile (100%)
rename drivers/{staging = mm}/zcache/tmem.c (100%)
rename
RE: [PATCH 0/4] promote zcache from staging
> From: Konrad Rzeszutek Wilk [mailto:kon...@darnok.org] > Sent: Friday, July 27, 2012 3:00 PM > Subject: Re: [PATCH 0/4] promote zcache from staging > > On Fri, Jul 27, 2012 at 12:21:50PM -0700, Dan Magenheimer wrote: > > > From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > > > Subject: [PATCH 0/4] promote zcache from staging > > > > > > zcache is the remaining piece of code required to support in-kernel > > > memory compression. The other two features, cleancache and frontswap, > > > have been promoted to mainline in 3.0 and 3.5. This patchset > > > promotes zcache from the staging tree to mainline. > > > > > > Based on the level of activity and contributions we're seeing from a > > > diverse set of people and interests, I think zcache has matured to the > > > point where it makes sense to promote this out of staging. > > > > Hi Seth -- > > > > Per offline communication, I'd like to see this delayed for three > > reasons: > > > > 1) I've completely rewritten zcache and will post the rewrite soon. > >The redesigned code fixes many of the weaknesses in zcache that > >makes it (IMHO) unsuitable for an enterprise distro. (Some of > >these previously discussed in linux-mm [1].) > > 2) zcache is truly mm (memory management) code and the fact that > >it is in drivers at all was purely for logistical reasons > >(e.g. the only in-tree "staging" is in the drivers directory). > >My rewrite promotes it to (a subdirectory of) mm where IMHO it > >belongs. > > 3) Ramster heavily duplicates code from zcache. My rewrite resolves > >this. My soon-to-be-post also places the re-factored ramster > >in mm, though with some minor work zcache could go in mm and > >ramster could stay in staging. > > > > Let's have this discussion, but unless the community decides > > otherwise, please consider this a NACK. Hi Konrad -- > Hold on, that is rather unfair. The zcache has been in staging > for quite some time - your code has not been posted. Part of > "unstaging" a driver is for folks to review the code - and you > just said "No, mine is better" without showing your goods. Sorry, I'm not trying to be unfair. However, I don't see the point of promoting zcache out of staging unless it is intended to be used by real users in a real distro. There's been a lot of discussion, onlist and offlist, about what needs to be fixed in zcache and not much visible progress on fixing it. But fixing it is where I've spent most of my time over the last couple of months. If IBM or some other company or distro is eager to ship and support zcache in its current form, I agree that "promote now, improve later" is a fine approach. But promoting zcache out of staging simply because there is urgency to promote zsmalloc+zram out of staging doesn't seem wise. At a minimum, it distracts reviewers/effort from what IMHO is required to turn zcache into an enterprise-ready kernel feature. I can post my "goods" anytime. In its current form it is better than the zcache in staging (and, please remember, I wrote both so I think I am in a good position to compare the two). I have been waiting until I think the new zcache is feature complete before asking for review, especially since the newest features should demonstrate clearly why the rewrite is necessary and beneficial. But I can post* my current bits if people don't believe they exist and/or don't mind reviewing non-final code. (* Or I can put them in a publicly available git tree.) > There is a third option - which is to continue the promotion > of zcache from staging, get reviews, work on them ,etc, and > alongside of that you can work on fixing up (or ripping out) > zcache1 with zcache2 components as they make sense. Or even > having two of them - an enterprise and an embedded version > that will eventually get merged together. There is nothing > wrong with modifying a driver once it has left staging. Minchan and Seth can correct me if I am wrong, but I believe zram+zsmalloc, not zcache, is the target solution for embedded. The limitations of zsmalloc aren't an issue for zram but they are for zcache, and this deficiency was one of the catalysts for the rewrite. The issues are explained in more detail in [1], but if any point isn't clear, I'd be happy to explain further. However, I have limited time for this right now and I'd prefer to spend it finishing the code. :-} So, as I said, I am still a NACK, but if there are good reasons to duplicate effort and pursue the "third option", let's discuss them. Thanks, Dan [1] http://marc.info/?t=13388670672=1=2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On Fri, Jul 27, 2012 at 12:21:50PM -0700, Dan Magenheimer wrote: > > From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > > Subject: [PATCH 0/4] promote zcache from staging > > > > zcache is the remaining piece of code required to support in-kernel > > memory compression. The other two features, cleancache and frontswap, > > have been promoted to mainline in 3.0 and 3.5. This patchset > > promotes zcache from the staging tree to mainline. > > > > Based on the level of activity and contributions we're seeing from a > > diverse set of people and interests, I think zcache has matured to the > > point where it makes sense to promote this out of staging. > > Hi Seth -- > > Per offline communication, I'd like to see this delayed for three > reasons: > > 1) I've completely rewritten zcache and will post the rewrite soon. >The redesigned code fixes many of the weaknesses in zcache that >makes it (IMHO) unsuitable for an enterprise distro. (Some of >these previously discussed in linux-mm [1].) > 2) zcache is truly mm (memory management) code and the fact that >it is in drivers at all was purely for logistical reasons >(e.g. the only in-tree "staging" is in the drivers directory). >My rewrite promotes it to (a subdirectory of) mm where IMHO it >belongs. > 3) Ramster heavily duplicates code from zcache. My rewrite resolves >this. My soon-to-be-post also places the re-factored ramster >in mm, though with some minor work zcache could go in mm and >ramster could stay in staging. > > Let's have this discussion, but unless the community decides > otherwise, please consider this a NACK. Hold on, that is rather unfair. The zcache has been in staging for quite some time - your code has not been posted. Part of "unstaging" a driver is for folks to review the code - and you just said "No, mine is better" without showing your goods. There is a third option - which is to continue the promotion of zcache from staging, get reviews, work on them ,etc, and alongside of that you can work on fixing up (or ripping out) zcache1 with zcache2 components as they make sense. Or even having two of them - an enterprise and an embedded version that will eventually get merged together. There is nothing wrong with modifying a driver once it has left staging. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
> From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] > Subject: [PATCH 0/4] promote zcache from staging > > zcache is the remaining piece of code required to support in-kernel > memory compression. The other two features, cleancache and frontswap, > have been promoted to mainline in 3.0 and 3.5. This patchset > promotes zcache from the staging tree to mainline. > > Based on the level of activity and contributions we're seeing from a > diverse set of people and interests, I think zcache has matured to the > point where it makes sense to promote this out of staging. Hi Seth -- Per offline communication, I'd like to see this delayed for three reasons: 1) I've completely rewritten zcache and will post the rewrite soon. The redesigned code fixes many of the weaknesses in zcache that makes it (IMHO) unsuitable for an enterprise distro. (Some of these previously discussed in linux-mm [1].) 2) zcache is truly mm (memory management) code and the fact that it is in drivers at all was purely for logistical reasons (e.g. the only in-tree "staging" is in the drivers directory). My rewrite promotes it to (a subdirectory of) mm where IMHO it belongs. 3) Ramster heavily duplicates code from zcache. My rewrite resolves this. My soon-to-be-post also places the re-factored ramster in mm, though with some minor work zcache could go in mm and ramster could stay in staging. Let's have this discussion, but unless the community decides otherwise, please consider this a NACK. Thanks, Dan [1] http://marc.info/?t=13388670672=1=2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] Subject: [PATCH 0/4] promote zcache from staging zcache is the remaining piece of code required to support in-kernel memory compression. The other two features, cleancache and frontswap, have been promoted to mainline in 3.0 and 3.5. This patchset promotes zcache from the staging tree to mainline. Based on the level of activity and contributions we're seeing from a diverse set of people and interests, I think zcache has matured to the point where it makes sense to promote this out of staging. Hi Seth -- Per offline communication, I'd like to see this delayed for three reasons: 1) I've completely rewritten zcache and will post the rewrite soon. The redesigned code fixes many of the weaknesses in zcache that makes it (IMHO) unsuitable for an enterprise distro. (Some of these previously discussed in linux-mm [1].) 2) zcache is truly mm (memory management) code and the fact that it is in drivers at all was purely for logistical reasons (e.g. the only in-tree staging is in the drivers directory). My rewrite promotes it to (a subdirectory of) mm where IMHO it belongs. 3) Ramster heavily duplicates code from zcache. My rewrite resolves this. My soon-to-be-post also places the re-factored ramster in mm, though with some minor work zcache could go in mm and ramster could stay in staging. Let's have this discussion, but unless the community decides otherwise, please consider this a NACK. Thanks, Dan [1] http://marc.info/?t=13388670672r=1w=2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] promote zcache from staging
On Fri, Jul 27, 2012 at 12:21:50PM -0700, Dan Magenheimer wrote: From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] Subject: [PATCH 0/4] promote zcache from staging zcache is the remaining piece of code required to support in-kernel memory compression. The other two features, cleancache and frontswap, have been promoted to mainline in 3.0 and 3.5. This patchset promotes zcache from the staging tree to mainline. Based on the level of activity and contributions we're seeing from a diverse set of people and interests, I think zcache has matured to the point where it makes sense to promote this out of staging. Hi Seth -- Per offline communication, I'd like to see this delayed for three reasons: 1) I've completely rewritten zcache and will post the rewrite soon. The redesigned code fixes many of the weaknesses in zcache that makes it (IMHO) unsuitable for an enterprise distro. (Some of these previously discussed in linux-mm [1].) 2) zcache is truly mm (memory management) code and the fact that it is in drivers at all was purely for logistical reasons (e.g. the only in-tree staging is in the drivers directory). My rewrite promotes it to (a subdirectory of) mm where IMHO it belongs. 3) Ramster heavily duplicates code from zcache. My rewrite resolves this. My soon-to-be-post also places the re-factored ramster in mm, though with some minor work zcache could go in mm and ramster could stay in staging. Let's have this discussion, but unless the community decides otherwise, please consider this a NACK. Hold on, that is rather unfair. The zcache has been in staging for quite some time - your code has not been posted. Part of unstaging a driver is for folks to review the code - and you just said No, mine is better without showing your goods. There is a third option - which is to continue the promotion of zcache from staging, get reviews, work on them ,etc, and alongside of that you can work on fixing up (or ripping out) zcache1 with zcache2 components as they make sense. Or even having two of them - an enterprise and an embedded version that will eventually get merged together. There is nothing wrong with modifying a driver once it has left staging. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/4] promote zcache from staging
From: Konrad Rzeszutek Wilk [mailto:kon...@darnok.org] Sent: Friday, July 27, 2012 3:00 PM Subject: Re: [PATCH 0/4] promote zcache from staging On Fri, Jul 27, 2012 at 12:21:50PM -0700, Dan Magenheimer wrote: From: Seth Jennings [mailto:sjenn...@linux.vnet.ibm.com] Subject: [PATCH 0/4] promote zcache from staging zcache is the remaining piece of code required to support in-kernel memory compression. The other two features, cleancache and frontswap, have been promoted to mainline in 3.0 and 3.5. This patchset promotes zcache from the staging tree to mainline. Based on the level of activity and contributions we're seeing from a diverse set of people and interests, I think zcache has matured to the point where it makes sense to promote this out of staging. Hi Seth -- Per offline communication, I'd like to see this delayed for three reasons: 1) I've completely rewritten zcache and will post the rewrite soon. The redesigned code fixes many of the weaknesses in zcache that makes it (IMHO) unsuitable for an enterprise distro. (Some of these previously discussed in linux-mm [1].) 2) zcache is truly mm (memory management) code and the fact that it is in drivers at all was purely for logistical reasons (e.g. the only in-tree staging is in the drivers directory). My rewrite promotes it to (a subdirectory of) mm where IMHO it belongs. 3) Ramster heavily duplicates code from zcache. My rewrite resolves this. My soon-to-be-post also places the re-factored ramster in mm, though with some minor work zcache could go in mm and ramster could stay in staging. Let's have this discussion, but unless the community decides otherwise, please consider this a NACK. Hi Konrad -- Hold on, that is rather unfair. The zcache has been in staging for quite some time - your code has not been posted. Part of unstaging a driver is for folks to review the code - and you just said No, mine is better without showing your goods. Sorry, I'm not trying to be unfair. However, I don't see the point of promoting zcache out of staging unless it is intended to be used by real users in a real distro. There's been a lot of discussion, onlist and offlist, about what needs to be fixed in zcache and not much visible progress on fixing it. But fixing it is where I've spent most of my time over the last couple of months. If IBM or some other company or distro is eager to ship and support zcache in its current form, I agree that promote now, improve later is a fine approach. But promoting zcache out of staging simply because there is urgency to promote zsmalloc+zram out of staging doesn't seem wise. At a minimum, it distracts reviewers/effort from what IMHO is required to turn zcache into an enterprise-ready kernel feature. I can post my goods anytime. In its current form it is better than the zcache in staging (and, please remember, I wrote both so I think I am in a good position to compare the two). I have been waiting until I think the new zcache is feature complete before asking for review, especially since the newest features should demonstrate clearly why the rewrite is necessary and beneficial. But I can post* my current bits if people don't believe they exist and/or don't mind reviewing non-final code. (* Or I can put them in a publicly available git tree.) There is a third option - which is to continue the promotion of zcache from staging, get reviews, work on them ,etc, and alongside of that you can work on fixing up (or ripping out) zcache1 with zcache2 components as they make sense. Or even having two of them - an enterprise and an embedded version that will eventually get merged together. There is nothing wrong with modifying a driver once it has left staging. Minchan and Seth can correct me if I am wrong, but I believe zram+zsmalloc, not zcache, is the target solution for embedded. The limitations of zsmalloc aren't an issue for zram but they are for zcache, and this deficiency was one of the catalysts for the rewrite. The issues are explained in more detail in [1], but if any point isn't clear, I'd be happy to explain further. However, I have limited time for this right now and I'd prefer to spend it finishing the code. :-} So, as I said, I am still a NACK, but if there are good reasons to duplicate effort and pursue the third option, let's discuss them. Thanks, Dan [1] http://marc.info/?t=13388670672r=1w=2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
