On Sat, Mar 5, 2011 at 6:06 PM, Ted Ts'o <tytso@xxxxxxx> wrote: > On Mon, Feb 21, 2011 at 10:02:44PM +0200, Amir Goldstein wrote: >> >> 1. (AKA easy lane) use a single page (or more) per block group. >> this will increase the memory usage for 1K blocks fs and for 2K block fs >> on 8K page system, but are these use cases really that common? > > The most common use cases will be 4k block file system on 16k page > systems, which show up on PowerPC and Itanium systems. OK. no easy way out. > >> 2. (AKA hard lane) attach buffer heads to buddy page and use >> buffer_uptodate() and buffer_lock() instead of PageUptodate() and lock_page() >> to initialize buddy cache of groups that share the same page. > > How about this; use lock_page() to guarantee exclusive access to the > shared buddy bitmap, and then define a new bit in > ext4_group_info->bb_state to indicate whether or not a particular > block group has been initialized. If the page has gotten flushed from > memory, so that it is not present at all (i.e., find_get_page returns > NULL), then iterate over all of the groups to clear the > EXT4_GROUP_INFO_BUDDY_INIT bit. > > If the page is returned by find_get_page(), then all you need to do is > check the EXT4_GROUP_INFO_BUDDY_INIT bit to discover whether or not or > not the buddy bitmap needs to be initialized. > That sounds about right, but why do I need a new bit? Why can't I use EXT4_GROUP_INFO_NEED_INIT_BIT to tell me the exact same thing? The only difference from current implementation is that I would have to test the bit again after taking page_lock(). I didn't have time to check the implementation into details yet. I will try to get to it during this week and send a tryout patch. Amir. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
