On Tue 15 Oct 2019 06:05:23 PM CEST, Eric Blake wrote:
>> 63 56 55 48 47 40 39 32 31 24 23 16 15 8 7 0
>> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> <---------------------------------> <--------------------------------->
>> subcluster reads as zeros subcluster is allocated
>> (32 bits) (32 bits)
>
> okay, in patch 5, you said you map the most significant bit to the
> first cluster. That feels backwards to me; I wonder if the math is any
> easier if you map sub-clusters starting from the least-significant,
> because then you get:
>
> bit = (address >> cluster_size) & 32
>
> rather than
>
> bit = 31 - ((address >> cluster_size) & 32)
The reason why I chose that ordering is because I think it's more
natural for debugging if you read from left to right:
63 56 55 48 47 40 39 32 31 24 23 16 15 8 7 0
00000000 00000000 00000000 00011111 11100000 00000000 00000000 00000000
<---------------------------------> <--------------------------------->
subcluster reads as zeros subcluster is allocated
Here the last five subclusters read as zeros, and the first three
subclusters are allocated.
I don't think the math is any different. What you need in the code is
1) A way to get the subcluster index. That doesn't change, it's
sc_index = (address >> cluster_bits) & 31
in both cases.
2) A way to get the "subcluster reads as zeros" and "subcluster is
allocated" masks. That's not very different either, it's a constant
shifted by the subcluster index in both cases:
LSB first:
all_zeros_mask = (1 << 32) << sc_index
allocated_mask = 1 << sc_index
MSB first:
all_zeros_mask = (1 << 63) >> sc_index
allocated_mask = (1 << 31) >> sc_index
>> Some comments about the results:
>>
>> - The smallest allowed cluster size for an image with subclusters is
>> 16 KB (in this case the subclusters size is 512 bytes), hence the
>> missing values in the 4 KB and 8 KB rows.
>
> Again reading ahead, I see that patch 5 requires a 16k minimum cluster
> for using extended L2. Could we still permit clusters smaller than
> that, but merely document that subclusters are always a minimum of 512
> bytes and therefore for an 8k cluster we only use 16 bits (leaving the
> other 16 bits zero)? But I'm also fine with the simplicity of just
> stating that subclusters require at least 16k clusters.
I can't think of any reason why you would want smaller clusters, the
numbers show that the performance starts to drop with sizes under 16KB.
> How do subclusters interact with external data files?
As far as I'm aware they work just fine (I'll add tests for that
anyway).
Berto
