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: <3BA1CBB1-77DB-43C8-A9CD-A3B85223F86F@dilger.ca>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_D9442292-9CC2-4651-B1E8-BC75A897C659";
 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:   Sun, 17 May 2020 01:55:07 -0600
In-Reply-To: <914597DA-395A-47A5-A8D6-DFCE2D674289@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>
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk


--Apple-Mail=_D9442292-9CC2-4651-B1E8-BC75A897C659
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

On May 15, 2020, at 2:56 AM, Alex Zhuravlev <azhuravlev@whamcloud.com> wrote:
> On 14 May 2020, at 13:04, Ritesh Harjani <riteshh@linux.ibm.com> wrote:
>>> +		/* cr=0/1 is a very optimistic search to find large
>>> +		 * good chunks almost for free. if buddy data is
>>> +		 * not ready, then this optimization makes no sense */
>> 
>> I guess it will be also helpful to mention a comment related to the
>> discussion that we had on why this should be ok to skip those groups.
>> Because this could result into we skipping the group which is closer to
>> our inode. I somehow couldn't recollect it completely.
> 
> Please remind where the discussion took place? I must be missing that.

Alex, this discussion was during the ext4 weekly developer concall.
I can send you the details if you want to join for next week's call.

The summary of the discussion is that Ted was wondering what happens if
one thread was scanning the filesystem and triggering prefetch on the
groups, but didn't find any loaded (so skips cr=0/1 passes completely),
then does an allocation in its preferred group (assuming there is space
available there, what happens to allocations for other inodes after this?

Presumably, the first thread's prefetch has loaded a bunch of groups, and
even if the second thread starts scanning for blocks at its preferred
group (though a different one from the first thread), it will skip all of
these groups until it finds the group(s) from the first inode allocation
are in memory already, and will proceed to allocate blocks there.

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.


Cheers, Andreas


--Apple-Mail=_D9442292-9CC2-4651-B1E8-BC75A897C659
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

iQIyBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAl7A7dsACgkQcqXauRfM
H+CjaQ/3er6hx4kt0imeFORldGMGuo7I1xFj2PIFYWxrIgK1vZ+9w6V4+T5+hJM4
fHBo4TNelOKD4H+As45sMemh++mm8t/+OU5nfqbrXQg+LGa2rvNHD6sXTyFAVP5E
UiZbPz4xMT+YFXkVkh/neqEYScdcWl6rBCeswvMhqryXHNAna1Vv0+dt4Cgzjz5w
SmKhGgfu5NDNawSLmOexl0PDAEZtV2eBQnxOoG98CEcliG6WIXm6s4P67YPF+Lkr
MdFLRLZ5c1frn2U56KVPqlDnsrpR5kKN2Ds/k5spJKWov/JGZh9Yqfl4xqbWo38j
03Ve7tDkD8X2C/G/GVWcqPUdDswPXlASKvWuH0+J7vtYvIVThscA3iXD+lSmgnSy
sYakoe+GcQvld/9PqqBI+PYw0EeFgPndembzQzLP1VMCisPdQEh1JdiYhpfp2dQB
0TC0fAWvpeMSRLsBu5761tsczTFBk1n7ljBcnRRJzGFYUUv9e2XkvKZp1x+RVHfU
FpCzWsUMBFWKgeaLSMLcZffqyYUf+7ScTbwSExfXJtK5Yvfpbj/N90iG5Sa8cMJ5
q2cXgpeJeme0VifmJFBBz1/lqezBbXzQ4EJ2ye/fOrIllRGdVs+qyoRja55yngKT
4cpTdnGzkP8BCF3Ew8DN3DC/cfTHOPRsBJv0VnvCuQztYjnOJA==
=gf6f
-----END PGP SIGNATURE-----

--Apple-Mail=_D9442292-9CC2-4651-B1E8-BC75A897C659--