From: Ted Ts'o <tytso@mit.edu>
To: Amir Goldstein <amir73il@gmail.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: ditching e4b->alloc_semp
Date: Sun, 6 Mar 2011 23:08:10 -0500 [thread overview]
Message-ID: <20110307040810.GE11120@thunk.org> (raw)
In-Reply-To: <AANLkTikW04brZ549=29N1Yan=GH29BN4WSVrA7erR_F6@mail.gmail.com>
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
next prev parent reply other threads:[~2011-03-07 4:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-21 20:02 ditching e4b->alloc_semp Amir Goldstein
2011-02-22 17:18 ` Andreas Dilger
2011-02-22 20:02 ` Amir Goldstein
2011-02-22 21:00 ` Andreas Dilger
2011-02-23 9:54 ` Amir Goldstein
2011-03-05 16:06 ` Ted Ts'o
2011-03-06 20:15 ` Amir Goldstein
2011-03-07 4:08 ` Ted Ts'o [this message]
2011-03-07 5:52 ` Amir Goldstein
2011-03-17 16:13 ` Amir Goldstein
2011-03-21 4:39 ` Amir Goldstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110307040810.GE11120@thunk.org \
--to=tytso@mit.edu \
--cc=amir73il@gmail.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).