On Mon, Sep 10, 2007 at 08:40:44AM -0400, Nicolas Pitre wrote: > > I think I am seeing something like this: > > - thread A gets data_request lock > > - thread A unlocks data_provider lock, signaling provider > > - thread A blocks getting data_ready lock > > - provider allocates work for A, unlocking data_ready to signal A > > - provider unlocks data_request lock, ready for next request > > - thread B gets data_request lock > > - thread B unlocks data_provider lock, signaling provider > > - thread B gets data_ready lock, because A still hasn't run yet > > - thread B tries to run on bogus data, since provider hasn't actually > > allocated any work yet > > Doh! > > OK I prefer the following fix as it doesn't need an additional lock. Sorry for the delayed response, but I didn't have time to play with this more until today. Patch looks good, and here are my new timings for fully repacking linux-2.6 on the 4-core box: threads = 1 real 3m41.330s user 3m34.729s sys 0m4.248s threads = 4 real 1m53.951s user 3m33.625s sys 0m6.556s threads = 6 real 1m59.775s user 3m33.929s sys 0m6.428s So there is definitely a performance improvement (though adding more threads than CPUs seems to hurt, rather than help, which means we are mostly keeping the processors busy), but the long writing phase starts to dominate as we get more CPUs. Most of the deltas are already being cached, so I'm not quite sure what is taking so long there. -Peff - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
