On Mon, Apr 19, 2010 at 10:48 PM, Josef Bacik <jo...@redhat.com> wrote: > On Mon, Apr 19, 2010 at 10:46:12PM +0800, Yan, Zheng wrote: >> On Mon, Apr 19, 2010 at 9:57 PM, Josef Bacik <jo...@redhat.com> 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, >
there is a check in do_chunk_alloc, so the later one will do nothing if the first call adds enough space. Yan Zheng -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
