On 12/30/2011 11:02 AM, Dan Magenheimer wrote: >> From: Seth Jennings [mailto:sjenning@xxxxxxxxxxxxxxxxxx] >> Sent: Friday, December 30, 2011 9:42 AM >> To: Greg Kroah-Hartman >> Cc: Seth Jennings; Dan Magenheimer; Brian King; devel@xxxxxxxxxxxxxxxxxxxx; linux- >> kernel@xxxxxxxxxxxxxxx >> Subject: [PATCH] staging: zcache: fix serialization bug in zv stats >> >> In a multithreaded workload, the zv_curr_dist_counts >> and zv_cumul_dist_counts statistics are being corrupted >> because the increments and decrements in zv_create >> and zv_free are not atomic. >> >> This patch converts these statistics and their corresponding >> increments/decrements/reads to atomic operations. >> >> Based on v3.2-rc7 >> >> Signed-off-by: Seth Jennings <sjenning@xxxxxxxxxxxxxxxxxx> > > I'm inclined to nack this change, at least unless inside an #ifdef DEBUG, > as these counts are interesting to a developer but not useful to a normal > end user, whereas the incremental cost for atomic_inc and atomic_dec are > non-trivial. I don't think any off-by-one in these counters could > result in a bug and, before promotion from staging, they probably > should just go away. (They are fun to "watch -d" though ;-) In my test, it hammers on particular chunk size and the counter is off by hundreds :-/ I too was worried about performance impact, however, my tests showed no degradation. That's probably because there are bigger bottlenecks elsewhere. Perhaps we can commit this for now, so that the code is correct, and revisit this when we try to replace zbud with zsmalloc. I'm sure we'll have to rethink the statistics at that time. The only other option, IMO, is the remove the chunk stats altogether until we can find a solution that is both fast and correct. I think that continuing with incorrect stats, regardless of the degree to which they are incorrect, isn't really a viable option. -- Seth _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
