> 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/
