All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jose R. Santos" <jrs@us.ibm.com>
To: Andreas Dilger <adilger@sun.com>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [RFC] Flex_BG ialloc awareness.
Date: Tue, 4 Dec 2007 16:51:19 -0600	[thread overview]
Message-ID: <20071204165119.38155a92@gara> (raw)
In-Reply-To: <20071203204247.GL3604@webber.adilger.int>

On Mon, 3 Dec 2007 13:42:47 -0700
Andreas Dilger <adilger@sun.com> wrote:

> On Dec 03, 2007  13:05 -0600, Jose R. Santos wrote:
> > @@ -600,6 +600,7 @@ void ext4_free_blocks_sb(handle_t *handle, struct super_block *sb,
> >  	ext4_grpblk_t group_freed;
> > +	ext4_group_t meta_group;
> 
> Please do not call these meta_groups.  This already means something very
> specific (i.e. desc_per_block groups) and using it for FLEX_BG is confusing.
> One possibly desirable relation is if the FLEX_BG count is some integer or
> power-of-two multiple of the metabg count.  That would allow the FLEX_BG
> code to share the same in-memory group struct as the mballoc code and save
> on some memory overhead.

Yes, need to clean the naming on some of these.  I also need to look
into the mballoc code to see if there is anything I can reuse.

> > +			meta_group = ext4_meta_group(sbi, block_group);
> > +			spin_lock(&sbi->s_meta_groups[meta_group].meta_group_lock);
> > +			sbi->s_meta_groups[meta_group].free_inodes++;
> > +			if (is_directory)
> > +				sbi->s_meta_groups[meta_group].num_dirs--;
> > +			spin_unlock(&sbi->s_meta_groups[meta_group].meta_group_lock);
> 
> This can be as many as hundreds or thousands of spin locks.  Why not use
> the same hashed locking code as the group descriptors themselves?
> 
> 		spin_lock(sb_bgl_lock(sbi, meta_group));
> 		spin_unlock(sb_bgl_lock(sbi, meta_group));
> 
> This scales with the number of CPUs and chance of contention is very low.

Excellent.  I was thinking that one spinlock per flex_bg was overkill
as well but I did not know the existence of blockgroup_lock.h.

> > +int find_group_meta(struct super_block *sb, struct inode *parent)
> > +{
> > +	ext4_group_t parent_mgroup = parent_group / sbi->s_groups_per_meta;
> 
> This could use ext4_meta_group(sbi, parent_group)?

Yes, thanks for catching.
 
> > +static inline ext4_group_t ext4_meta_group(struct ext4_sb_info *sbi,
> > +					     ext4_group_t block_group)
> > +{
> > +	return block_group/sbi->s_groups_per_meta;
> > +}
> 
> It would be preferable to limit s_groups_per_meta to be a power-of-two
> so that this can become a shift instead of a divide.

Seems like I always fall into the same trap.  I'll change this.

> Cheers, Andreas
> --
> Andreas Dilger
> Sr. Staff Engineer, Lustre Group
> Sun Microsystems of Canada, Inc.
> 

Thanks.

-JRS

      reply	other threads:[~2007-12-04 22:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-03 19:05 [RFC] Flex_BG ialloc awareness Jose R. Santos
2007-12-03 20:42 ` Andreas Dilger
2007-12-04 22:51   ` Jose R. Santos [this message]

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=20071204165119.38155a92@gara \
    --to=jrs@us.ibm.com \
    --cc=adilger@sun.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.