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. > >> 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. > I didn't need to use EXT4_GROUP_INFO_BUDDY_INIT after all. That state could be obtained from page uptodate bit. See patches posted on the list. Cheers, 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
