All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thavatchai Makphaibulchoke <thavatchai.makpahibulchoke@hp.com>
To: Andreas Dilger <adilger@dilger.ca>, George Spelvin <linux@horizon.com>
Cc: T Makphaibulchoke <tmac@hp.com>, Andi Kleen <andi@firstfloor.org>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 0/3] ext4: increase mbcache scalability
Date: Tue, 28 Jan 2014 13:07:20 -0700	[thread overview]
Message-ID: <52E80DF8.7050602@hp.com> (raw)
In-Reply-To: <848E47EB-5FDF-4DB9-9800-4B1F4B1FA71C@dilger.ca>

On 01/28/2014 02:09 PM, Andreas Dilger wrote:
> On Jan 28, 2014, at 5:26 AM, George Spelvin <linux@horizon.com> wrote:
>>> The third part of the patch further increases the scalablity of an ext4
>>> filesystem by having each ext4 fielsystem allocate and use its own private
>>> mbcache structure, instead of sharing a single mcache structures across all
>>> ext4 filesystems, and increases the size of its mbcache hash tables.
>>
>> Are you sure this helps?  The idea behind having one large mbcache is
>> that one large hash table will always be at least as well balanced as
>> multiple separate tables, if the total size is the same.
>>
>> If you have two size 2^n hash tables, the chance of collision is equal to
>> one size  2^(n+1) table if they're equally busy, and if they're unequally
>> busy. the latter is better.  The busier file system will take less time
>> per search, and since it's searched more often than the less-busy one,
>> net win.
>>
>> How does it compare with just increasing the hash table size but leaving
>> them combined?
> 
> Except that having one mbcache per block device would avoid the need
> to store the e_bdev pointer in thousands/millions of entries.  Since
> the blocks are never shared between different block devices, there
> is no caching benefit even if the same block is on two block devices.
> 
> Cheers, Andreas
> 
> 
> 
> 
> 

Thanks George and Andreas for the comments.  Andreas you mentions a good point, e_bdev pointer is not needed when having one mb_cache for each block device.  I'll integrate that into my patch, removing the e_bdev pointer, and run some comparison between one large hash table vs multiple hash tables, as suggested by George.

Thanks,
Mak.

  reply	other threads:[~2014-01-28 20:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-28 12:26 [PATCH v4 0/3] ext4: increase mbcache scalability George Spelvin
2014-01-28 21:09 ` Andreas Dilger
2014-01-28 20:07   ` Thavatchai Makphaibulchoke [this message]
2014-02-11 18:47   ` Thavatchai Makphaibulchoke
  -- strict thread matches above, loose matches on Subject: below --
2013-08-22 15:54 [PATCH v2 0/2] " T Makphaibulchoke
2014-01-24 18:31 ` [PATCH v4 0/3] " T Makphaibulchoke
2014-01-24 21:38   ` Andi Kleen
2014-01-25  1:13     ` Thavatchai Makphaibulchoke
2014-01-25  6:09     ` Andreas Dilger
2014-01-27 12:27       ` Thavatchai Makphaibulchoke
2014-02-09 19:46       ` Thavatchai Makphaibulchoke
2014-02-11 19:58       ` Thavatchai Makphaibulchoke
2014-02-13  2:01         ` Andreas Dilger

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=52E80DF8.7050602@hp.com \
    --to=thavatchai.makpahibulchoke@hp.com \
    --cc=adilger@dilger.ca \
    --cc=andi@firstfloor.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@horizon.com \
    --cc=tmac@hp.com \
    /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.