Re: ditching e4b->alloc_semp

[Amir Goldstein <amir73il@gmail.com>]

On Sat, Mar 5, 2011 at 6:06 PM, Ted Ts'o <tytso@mit.edu> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html