Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Andreas Dilger <adilger@dilger.ca>
Message-Id: <DDB9F79B-55A9-4667-AE03-60D575CAD77A@dilger.ca>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_8C771D9C-CB62-45D8-A6D3-BD59C1E1BAC8";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [PATCH 2/2] ext4: skip non-loaded groups at cr=0/1
Date:   Wed, 20 May 2020 13:34:03 -0600
In-Reply-To: <3158FFEB-D9F7-450B-85C5-38B1C218321F@whamcloud.com>
Cc:     Ritesh Harjani <riteshh@linux.ibm.com>,
        "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
To:     Alex Zhuravlev <azhuravlev@whamcloud.com>
References: <0B6BF408-EDF7-4363-80CD-BDA0136BF62C@whamcloud.com>
 <20200514100411.D1A15A405C@b06wcsmtp001.portsmouth.uk.ibm.com>
 <914597DA-395A-47A5-A8D6-DFCE2D674289@whamcloud.com>
 <3BA1CBB1-77DB-43C8-A9CD-A3B85223F86F@dilger.ca>
 <3158FFEB-D9F7-450B-85C5-38B1C218321F@whamcloud.com>
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk


--Apple-Mail=_8C771D9C-CB62-45D8-A6D3-BD59C1E1BAC8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On May 20, 2020, at 2:40 AM, Alex Zhuravlev <azhuravlev@whamcloud.com> =
wrote:
>=20
>=20
>=20
>> On 17 May 2020, at 10:55, Andreas Dilger <adilger@dilger.ca> wrote:
>>=20
>> The question is whether this is situation is affecting only a few =
inode
>> allocations for a short time after mount, or does this persist for a =
long
>> time?  I think that it _should_ be only a short time, because these =
other
>> threads should all start prefetch on their preferred groups, so even =
if a
>> few inodes have their blocks allocated in the "wrong" group, it =
shouldn't
>> be a long term problem since the prefetched bitmaps will finish =
loading
>> and allow the blocks to be allocated, or skipped if group is =
fragmented.
>=20
> Yes, that=E2=80=99s the idea - there is a short window when buddy data =
is being
> populated. And for each =E2=80=9Ccluster=E2=80=9D (not just a single =
group) prefetching
> will be initiated by allocation.
> It=E2=80=99s possible that some number of inodes will get =E2=80=9Cbad=E2=
=80=9D blocks right after
> after mount.
> If you think this is a bad scenario I can introduce couple more =
things:
> 1) few times discussed prefetching thread
> 2) let mballoc wait for the goal group to get ready - this essentials =
one
>    more check in ext4_mb_good_group()

IMHO, this is an acceptable "cache warmup" behavior, not really =
different
than mballoc doing limited scanning when looking for any other =
allocation.
Since we already separate inode table blocks and data blocks into =
separate
groups due to flex_bg, I don't think any group is "better" than another,
so long as the allocations are avoiding worst-case fragmentation (i.e. a
series of one-block allocations).

Cheers, Andreas


--Apple-Mail=_8C771D9C-CB62-45D8-A6D3-BD59C1E1BAC8
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAl7FhisACgkQcqXauRfM
H+AO9Q/9FzfLeFFXTgs0LB5d49mldVY8/aeuqshI1P07XOeUmkHGltQR8Y1FS7Az
fGeoqugxNBKJRz4jJSG6lNWSwSwdsWHYuFXH59rJvH7WZy9nUbBcc8O0RXp8PpFN
TKCgQDERZ3jiYyjSV7uEinYjzuhLmUJk734eA7Nt9j3ghaPEMw5ZGS6cK/tNccav
F5VLyR61IhqKU9hKgSOCNu8z/WRQBBlX/BFVXB166Nm/esX8QsftI2mJvQQmvEOH
vGxc8OOjgiRHbpj03AeJg5lRUGIt9JObSTyn2ECgTDY5bEPf1Je8PceNlbaOppg1
NCNK90uEOhscrLzmYIBcasBzMV2t3MbbivzsH4Y2ZDxeb7XFnuNdqAgsH5wkUuto
Cb6iPYIzgVF35PGhy6+Ts+t2uYbhM6HevyVFlAvsPBfaznbIGwyfRvvlQGt2Iowm
pr7t+UIBaBiZ9XJZBcX6qvkirpFynrtkcWGjjHlDW8wV4n4m7AAfS8DNg4PaENHa
MzZl7kUCj9FA8uca8ZF/VXxsnYc1np83U9KUMBnAKdWnE6mVGlTUnhk90b7y1zQu
EywV4S4CGQm/pVqL2dbjIypuTwkPPEEjG9k1eqz8OXJfYpKZn6ip0RJm1r0LRkSR
oA3GY+Ck+kpnvMzIMBuSQcVpSvkmtbTM99mnxJftQziIN72jLE0=
=fD+P
-----END PGP SIGNATURE-----

--Apple-Mail=_8C771D9C-CB62-45D8-A6D3-BD59C1E1BAC8--