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