Messages in this thread | | | Date | Fri, 17 Aug 2012 15:21:22 -0700 (PDT) | From | Dan Magenheimer <> | Subject | RE: [PATCH 0/4] promote zcache from staging |
| |
> From: Seth Jennings [mailto:sjenning@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
| |