linux-ext4 - Re: [PATCH] ext4: start seraching for the right extent from the goal group.

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>] [day] [month] [year] [list]

Message-ID: <20080501154824.GB7005@skywalker>
Date:	Thu, 1 May 2008 21:18:24 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Valerie Clement <valerie.clement@...l.net>
Cc:	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] ext4: start seraching for the right extent from the
	goal group.

On Wed, Apr 30, 2008 at 04:15:11PM +0200, Valerie Clement wrote:
> Aneesh Kumar K.V wrote:
>> With mballoc we search for the best extent using different
>> criteria. We should always use the goal group when we are
>> starting with a new criteria.
>
> Hi Aneesh,
>
> as you are working on the mballoc code, there is another thing
> which is not clear for me: why skipping uninitialized groups in  
> ext4_mb_good_group() when criteria is 0.
> I'm doing tests on large partition (~2TB) and on FS with 1KB
> block size and it impacts the performance when the number of
> groups is great (and the uninit_groups feature is used of course).
> For which reason we skip these groups ?
>

The reason is to avoid initializing block group. We would like to make
sure when we are allocating blocks we allocate them from already
initialized group. Otherwise we would end up initializing multiple block
group with in turn decrease the performance advantage of uninit_group.

The current logic is.

If request len is order of 2 we start with cr=0.

If we are cr=0 skip the uninit block group and search for the right
count of blocks in other initialized block group using simple_scan
logic.

If we don't find the right count of blocks then cr++;

if cr != 0 don't skip uninit block group.

if group is uninit and the request size is order of 2 use the
simple_scan logic which use buddy cache to search for the right count of
block group.

That way we avoid allocating blocks out of uninit group in the first
loop. We allocate blocks only after we looked at all the other
initialized block group.

-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html