linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Sat, 5 Mar 2011 11:06:56 -0500	[thread overview]
Message-ID: <20110305160656.GA3505@thunk.org> (raw)
In-Reply-To: <AANLkTikSLsuiZGYaUKtQnMQNZ6Pj=K_RDkYtpK98ujy1@mail.gmail.com>

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.

							- Ted

  parent reply	other threads:[~2011-03-06  0:13 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 [this message]
2011-03-06 20:15   ` Amir Goldstein
2011-03-07  4:08     ` Ted Ts'o
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=20110305160656.GA3505@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).