Re: ditching e4b->alloc_semp

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Mar 06, 2011 at 10:15:41PM +0200, Amir Goldstein wrote:
> 
> 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 current meaning of NEED_INIT_BIT is that it indicates that the
group has been initialized once since the file system has been
mounted.  It is used by ext4_mb_good_group() to know whether it can
rely on ext4_group_info->bb_free, ext4_group_info->bb_fragments,
ext4_group_info->bb_largest_free_order, et. al, without needing to
reload the buddy bitmap.

We added this so that even if memory pressure has forced the buddy
bitmap and block allocation bitmaps out of memory, we have enough
information in the ext4_group_info summary array that we can quickly
decide whether or not a group is a likely good candidate to be
examined more closely to have the necessary free blocks.  Without this
(relatively recent) change, the mballoc code might potentially need to
read in tens if not hundreds of block allocation bitmaps only to find
that it didn't have enough contiguous blocks, and then the memory
pressure would push the block bitmap out of memory again.... and file
system performance would go into the toilet.


So we don't want to disturb the meaning of this particular bit.  If we
zap the NEED_INIT_BIT whenever we discover that the group's buddy
bitmap page has been pushed out of memory, then we will once again
need to read in massive numbers of block bitmaps because clearing the
bit effectively marks the summary information stored ext4_group_info
structure as invalid.

							- Ted
--
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


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux