linux-ext4 - Re: [PATCH v4 0/3] ext4: increase mbcache scalability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <848E47EB-5FDF-4DB9-9800-4B1F4B1FA71C@dilger.ca>
Date:	Tue, 28 Jan 2014 14:09:15 -0700
From:	Andreas Dilger <adilger@...ger.ca>
To:	George Spelvin <linux@...izon.com>
Cc:	T Makphaibulchoke <tmac@...com>, Andi Kleen <andi@...stfloor.org>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 0/3] ext4: increase mbcache scalability

On Jan 28, 2014, at 5:26 AM, George Spelvin <linux@...izon.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






Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)