On Mon, Apr 19, 2010 at 10:46:12PM +0800, Yan, Zheng wrote: > On Mon, Apr 19, 2010 at 9:57 PM, Josef Bacik <josef@xxxxxxxxxx> wrote: > > The purpose of maybe_allocate_chunk was that there is no way to know if some > > other CPU is currently trying to allocate a chunk for the given space info. We > > could have two cpu's come inot do_chunk_alloc at relatively the same time and > > end up allocating twice the amount of space, which is why I did the waitqueue > > thing. It seems like this is still a possibility with your patch. Thanks, > > > This is impossible because the very first thing do_chunk_alloc does is > lock the chunk_mutex. > Sure, that just means we don't get two things creating chunks at the same time, but not from creating them one right after another. So CPU 0 and 1 come in to the check free space stuff, realize they need to allocate a chunk, and race to call do_chunk_alloc. One of them wins, and the other blocks on the chunk_mutex lock. When the first finishes the other one is able to continue and do what it was originally going to do, and then you get two chunks when you really only wanted one. Thanks, Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
