On Wed, Jul 12, 2023 at 03:40:01PM -0700, Darrick J. Wong wrote:
> On Tue, Jun 20, 2023 at 02:32:12PM -0700, Omar Sandoval wrote:
> > From: Omar Sandoval <osandov@xxxxxx>
> >
> > In commit 355e3532132b ("xfs: cache minimum realtime summary level"), I
> > added a cache of the minimum level of the realtime summary that has any
> > free extents. However, it turns out that the _maximum_ level is more
> > useful for upcoming optimizations, and basically equivalent for the
> > existing usage. So, let's change the meaning of the cache to be the
> > maximum level + 1, or 0 if there are no free extents.
>
> Hmm. If I'm reading xfs_rtmodify_summary_int right, m_rsum_cache[b] now
> tells us the maximum log2(length) of the free extents starting in
> rtbitmap block b?
>
> IOWs, let's say the cache contents are:
>
> {2, 3, 2, 15, 8}
>
> Someone asks for a 400rtx (realtime extent) allocation, so we want to
> find a free space of at least magnitude floor(log2(400)) == 8.
>
> The cache tells us that there aren't any free extents longer than 2^1
> blocks in rtbitmap blocks 0 and 2; longer than 2^2 blocks in rtbmp block
> 1; longer than 2^7 blocks in rtbmp block 4; nor longer than 2^14 blocks
> in rtbmp block 3?
There's a potential for an off-by-one bug here, so just to make sure
we're saying the same thing: the realtime summary for level n contains
the number of free extents starting in a bitmap block such that
floor(log2(size_in_realtime_extents)) == n. The maximum size of a free
extent in level n is therefore 2^(n + 1) - 1 realtime extents.
So in your example, the cache is telling us that realtime bitmap blocks
0 and 2 don't have anything free in levels 2 or above, and therefore
don't have any free extents longer than _or equal to_ 2^2.
I'll try to reword the commit message and comments to make this
unambiguous.
